Re: [OAUTH-WG] Possible alternative resolution to issue 26

William Mills <wmills@yahoo-inc.com> Tue, 04 October 2011 04:55 UTC

Return-Path: <wmills@yahoo-inc.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B821F8EC2 for <oauth@ietfa.amsl.com>; Mon, 3 Oct 2011 21:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.383
X-Spam-Level:
X-Spam-Status: No, score=-17.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWLR1LxHWeds for <oauth@ietfa.amsl.com>; Mon, 3 Oct 2011 21:55:35 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.ac4.yahoo.com (nm10-vm0.bullet.mail.ac4.yahoo.com [98.139.53.194]) by ietfa.amsl.com (Postfix) with SMTP id EF58421F8E50 for <oauth@ietf.org>; Mon, 3 Oct 2011 21:55:34 -0700 (PDT)
Received: from [98.139.52.192] by nm10.bullet.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000
Received: from [98.139.52.131] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000
Received: from [127.0.0.1] by omp1014.mail.ac4.yahoo.com with NNFMP; 04 Oct 2011 04:58:36 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 353003.15269.bm@omp1014.mail.ac4.yahoo.com
Received: (qmail 5454 invoked by uid 60001); 4 Oct 2011 04:58:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317704315; bh=g+MzH2L6+X5oG/PlTXh7/dlTF47loTpA6EK8v/vvVK8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bJqmBszbr3aoUEgZoqkWVHtdWy6vws1M0MSMhPQSzIXXscVPOql/ul87OnE0uEN6XtQQRHgeKW2rHhP+f9n1cv8ETqSvU05AG+QxDRS8nZjd8dA1N2DwmNHZYNJyawb3FkmIIW0GWQv+Mzh2ukpzlP88/fBlft4UGiLHgTrHj58=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Dr7ogzIFbcLlhIiSqpTKz3gGnccGuExVWBfQz/J2ioPYFDc+i4BnHCsONcLOZ1wr5ZBbvkRTQ6DMQXmKD86WsWlU/r/IEJSmx9rx/pCi94ZxMRBNvCgeAUEDhXFyqvuWhfkoSsFGQe2hxcGudIZP9dFewHa3GYQUii9eOY2uCvs=;
X-YMail-OSG: Zo1FP54VM1k_GGrs5fJc5Bv_YE9AR8jU4k5x1IpHJc8RQQU OojxBaoRTqhr5KrtWH1T1oX2.3OD8BrzgOf8F2nf1GhAXvQf3RVvkoXqrGUr kGjJ4mFKQhnw9ieAHA5ilwBZKP9OLoWJ6KvEQbKrsSXXHbAG3zn6jsdJDzEG _DBJndkNKK4o30_sj8trpHbSuNi9on4tS.nDIx_hfLxznpekeLB1ABFNWo6F LB.dJ5PT1ZhcY4RJMORCyThg_Ipf8jLfZABbo.AANffUKiiFo6TetpU9iv0F mda1OYFHxBDusTo.2BZkHr2i2f8zp79_Pza9TsVT0pFxdeXFOnrNliFlMddm K9H_5C_BM3NWZJEu4HYqtB.d68c2e4zbLn15UfSuA7J1Pix3ArDAySx7ISLA p3cGx3ngemcYKfQTqV0UYSGOEJDg79hELUUzvhcM7fDzDPw1IdUdeTmI2z8d pMyqXSA--
Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Mon, 03 Oct 2011 21:58:35 PDT
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.115.325013
References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com>
Message-ID: <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Mon, 03 Oct 2011 21:58:35 -0700
From: William Mills <wmills@yahoo-inc.com>
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-510387924-1317704315=:93442"
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 04:55:36 -0000

You forgot:

4.  Restrict the character set for scope to the point where these issues all go away.



________________________________
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Cc: "Manger, James H" <James.H.Manger@team.telstra.com>; William Mills <wmills@yahoo-inc.com>
Sent: Monday, October 3, 2011 6:55 PM
Subject: RE: [OAUTH-WG] Possible alternative resolution to issue 26


 
As editor, based upon James’ input, I’d like to expand the set of choices for the working group to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding are restricted to the set of 7-bit ASCII characters compatible with the HTTPbis and RFC 2617 parameter syntaxes.
 
1.  Using RFC 5987 encoding for the scope parameter.
2.  Continuing to specify no non-ASCII encoding for scope parameter values.
3.  Using JSON string encoding for the scope parameter.
 
A.  Using RFC 5987 encoding for the error_description parameter.
B.  Continuing to specify UTF-8 encoding for the error_description parameter.
C.  Using JSON string encoding for the error_description parameter.
 
As an individual, I’m sympathetic to the argument that RFC 5987 (with “scope*” and language tags etc.) is overkill for OAuth implementations, where neither of the sets of strings is intended to be presented to end-users.  Hence, the possible attractiveness of options 3 and C.
 
Thoughts from others?
 
                                                                -- Mike
 
From:William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Sunday, October 02, 2011 11:01 PM
To: Manger, James H; Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
 
I don't like dropping scope from the WWW-Authenticate responses, because my current discovery usage requires scope to be returned so that it can be passed to the auth server if the user is forced to re-authenticate.
 
+1 for "explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it."



________________________________
 
From:"Manger, James H" <James.H.Manger@team.telstra.com>
To: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Sunday, October 2, 2011 5:50 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
The best solution is to drop the “scope” field from the “WWW-Authenticate: Bearer ...” response header. “scope” is relevant to an OAuth2-core flow, not to presenting a bearer token. “scope” could make sense in a “WWW-Authenticate: OAuth2 ...” response header as long as other necessary details such as an authorization URI were also provided. Dropping “scope” and “error_description” (as the error should be described in the response body) would eliminate these encoding problems.
 
 
If the group really wants to keep “scope”, I don’t think RFC 5987 is a good solution. RFC 5987 might have been ok for adding internationalization support to long-standing ASCII-only fields in a world of multiple character sets – but none of that applies here. Having to change the field name from “scope” to “scope*” when you have a non-ASCII value is the biggest flaw.
 
The simplest solution is to explicitly restrict scope values to some subset of printable ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is slightly disappointing, but I can live with it.
 
My preferred escaping solution would be a JSON string, UTF-8 encoded: json.org, RFC 4627; value in double-quotes; slash is the escape char; supports Unicode; eg scope="coll\u00E8gues". This is backward-compatible with HTTP’s quoted-string syntax. It is forward-compatible with UTF-8 HTTP headers (if that occurs). JSON is well-supported (and required for other OAuth2 exchanges). [I might suggest json-string to the httpbis group as a global replacement for quoted-string (or at least as a recommendation for new fields).]
 
--
James Manger
 
From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible alternative resolution to issue 26
 
There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence.  If we decide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice.  I’d be interested in knowing how many working group members are in favor of either:
 
1.  Using RFC 5987 encoding for the scope parameter.
2.  Continuing to specify no non-ASCII encoding for scope parameter values.
 
As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead.  I’d also be interested in knowing how many working group members are in favor of either:
 
A.  Using RFC 5987 encoding for the error_description parameter.
B.  Continuing to specify UTF-8 encoding for the error_description parameter.
 
(As editor, I would make the observation that if we choose RFC 5987 encoding for either of these parameters, it would be logical to do so for the other one as well.)
 
In the interest of finishing the specification in a way that meets everyone’s needs,
                                                            -- Mike
 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth