On Oct 4, 2011, at 2:38 PM, Marius Scurtescu wrote: > On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <michael.jo...@microsoft.com> > wrote: > Existing practice is that simple ASCII strings like “email” “profile”, > “openid”, etc. are used as scope elements. Requiring them to be URIs would > break most existing practice. > > > Aren't these simple strings URIs? I think they are parsed as a URI with no > scheme and authority only a path.
Is there a need to parse these things as URIs semantically-speaking? Why wouldn't we restrict the character set of scopes to be those possible in a URI, but not say they have to be URIs semantically? I'd hate to require them to actually be URIs... - John > > Marius > > > > > -- Mike > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Marius Scurtescu > Sent: Tuesday, October 04, 2011 11:01 AM > To: Phil Hunt > Cc: oauth@ietf.org WG > > > Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 > > > > I just realized that scopes are defined as a space separated list of strings, > for some reason I though they are a list of URIs. > > > > Mark Lentczner just clarified for me that URIs are supposed to be ASCII only. > IRIs can have non-ASCII characters and can be canonically converted to URIs > using percent encoding (back to square one). > > > > If the core spec defines scope as list of URIs then the whole issue goes > away. Any reason not to do that? > > > > Marius > > > On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt <phil.h...@oracle.com> wrote: > > I very much agree with you there. As I said, simple roles are best and are > by far the primary case. > > > > I'm just not so sure we should close the door. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.h...@oracle.com > > > > > > > > On 2011-10-04, at 9:58 AM, William Mills wrote: > > > > > I don't believe that scope is the right place to carry a more complex grant, > those would live in the token. That would more logically go in the token. > XML gets weird when you get to the part about space separationoand order > doesn't matter. Scope's current definition makes it incompatible in sublte > ways with using it for XML. > > > > From: Phil Hunt <phil.h...@oracle.com> > To: "oauth@ietf.org WG" <oauth@ietf.org> > Sent: Tuesday, October 4, 2011 9:47 AM > Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 > > In most cases, scope has just been a set of simple "roles" as in > "readProfile", "updateStatus", etc. > > I tend to agree scope is an internal value that SHOULD never be seen by > end-users (this should be made clear). The meaning of a scope must be > conveyed in authorization dialog, the how of which is out of scope. Since > the resource server defines how it scopes information, it should be able to > explain the meaning of a scope request in localized language. > > I'm not against encoding the value if necessary to handle non-printable > characters. The issue I think comes back to complexity for the clients. Would > such encoding be problematic for the clients envisioned? > > Some examples I can think of: > * A URL to a specific resource > * An XML or JSON structure representing a more complex "grant" or policy > statement > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-10-04, at 9:01 AM, Michael Thomas wrote: > > > On 10/03/2011 09:58 PM, William Mills wrote: > >> You forgot: > >> > >> 4. Restrict the character set for scope to the point where these issues > >> all go away. > > > > Assuming that this is *completely* internal, and no end users will ever > > see either of these, this seems like the most prudent if interoperability > > is the primary goal. The principle of least surprise, and all. > > > > But completely internal is impossible to guarantee, so I guess the question > > is whether an incomprehensible katakana-encoded message/token is any > > worse than an incomprehensible ascii-7 english one to the poor end user > > who's trying to make sense of it. If it isn't then keeping things simple is > > probably safer. I assume the reason that 5987 exists is because as a > > whole, http shouldn't make any assumptions about whether users will > > see header field data. But these are individual cases here, not a > > protocol-wide > > mandate. > > > > Mike > > > >> > >> ------------------------------------------------------------------------ > >> *From:* Mike Jones <michael.jo...@microsoft.com> > >> *To:* "oauth@ietf.org" <oauth@ietf.org> > >> *Cc:* "Manger, James H" <james.h.man...@team.telstra.com>; William Mills > >> <wmi...@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:wmi...@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.man...@team.telstra.com > >> <mailto:james.h.man...@team.telstra.com>> > >> *To:* Mike Jones <michael.jo...@microsoft.com > >> <mailto:michael.jo...@microsoft.com>>; "oauth@ietf.org > >> <mailto:oauth@ietf.org>" <oauth@ietf.org <mailto: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 <http://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-boun...@ietf.org <mailto:oauth-boun...@ietf.org> > >> [mailto:oauth-boun...@ietf.org] <mailto:[mailto:oauth-boun...@ietf.org]> > >> *On Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* oauth@ietf.org <mailto: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 <http://tools.ietf.org/html/rfc5987> (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 <mailto:OAuth@ietf.org> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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
