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-boun...@ietf.org [mailto:oauth-boun...@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.tschofe...@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.tschofe...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
