Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

In your note yesterday summarizing our proposed issue resolutions, you wrote "The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any internationalization support here either."

I'm therefore confused by your note below, Hannes, as it seems to me to contradict both your statement above.  In particular, there's no need for Unicode encodings when internationalization isn't required.  ASCII characters are fine for representing machine-readable scope elements that will never be displayed to users.  That's the approach I'm taking in draft 10.  (And indeed, EVERY draft of the bearer token spec has specified only ASCII characters, so this is nothing new...)

				-- Mike

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] 
Sent: Saturday, October 15, 2011 5:16 AM
To: Mike Jones; Hannes Tschofenig
Cc: OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

this is not specific enough. A string could be defined as "
A string is a sequence of zero or more Unicode characters [UNICODE].
"
(as in RFC 4627), or as
"
8-bit binary data without a NUL (hex 00) termination "
(as in RADIUS, RFC 2865). 

In any case, we have to consider the constraints from the usage of "application/x-www-form-urlencoded". In our specific case this means that we have to get from the scope string to an octet sequence, which is allowed by application/x-www-form-urlencoded.

Julian had pointed to this issue already (see mail from October 7th).

If you want any string (with the exception of SP, which is the
delimiter) then you have to choose an encoding that is able to represent Unicode in ASCII. There are a few choices and according to Julian the following options exist:

a) RFC 5987
b) URI encoding to UTF-8 encoding
(which is essentially like RFC 5987 but to omit the language part of the
triple)
c) JSON (with the problem that the "\" notation in the quoted-string)

If you want to go along this route then I would suggest to go for (a) and to include a couple of examples (see Section 3.2.2 of RFC 5987 for examples). This is clearly better than inventing a new mechanism ourselves. The language tag is optional and RFC 5987 only requires parser support for UTF-8 and ISO-8859-1. 

Ciao
Hannes

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Mike Jones
Sent: Friday, October 14, 2011 10:40 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Any strings that the Authorization Server chooses to define meanings for

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Friday, October 14, 2011 12:28 PM
To: Mike Jones
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

what values do we want to support? 

We know that from the base specification we want a list of space-delimited, case sensitive strings.

We don't want support for internationalized character-sets. 

Ciao
Hannes

On Oct 14, 2011, at 9:32 PM, Mike Jones wrote:

> The core spec says "The strings are defined by the authorization
server" (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3).  I don't see a reason to change that - especially this late in the game.  I am not introducing any standardized or reserved values.
> 
> My intent is not require or even suggest that scope values should be
URIs.  My intent is to not preclude them from being so.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
> Sent: Friday, October 14, 2011 11:27 AM
> To: Mike Jones
> Cc: Hannes Tschofenig; OAuth WG
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
Proposed Resolutions
> 
> Hi Mike,
> 
> On Oct 14, 2011, at 6:42 PM, Mike Jones wrote:
> 
>> 2.  Scope - I was planning to allow a broader set of ASCII characters
than the "token" set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elements need to permit the full sets of "reserved" and "unreserved" characters in RFC 3986.  The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the "reserved" and "unreserved" sets.
> 
> Wouldn't it be more useful to say that you either want some plaintext
values for the scope or URLs but not both?
> 
> Also, if you want to introduce "standardized" (or reserved values)
then you have to 
> a) specify them now (with no ability to change them), or
> b) prefix them.
> 
> Ciao
> Hannes
> 
> 

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