On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <[email protected]>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. Marius > **** > > ** ** > > -- Mike**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Marius Scurtescu > *Sent:* Tuesday, October 04, 2011 11:01 AM > *To:* Phil Hunt > *Cc:* [email protected] 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 <[email protected]> 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**** > > [email protected]**** > > ** ** > > ** ** > > ** ** > > 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 <[email protected]> > *To:* "[email protected] WG" <[email protected]> > *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 > [email protected] > > > > > > 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 <[email protected]> > >> *To:* "[email protected]" <[email protected]> > >> *Cc:* "Manger, James H" <[email protected]>; William > Mills <[email protected]> > >> *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:[email protected]] > >> *Sent:* Sunday, October 02, 2011 11:01 PM > >> *To:* Manger, James H; Mike Jones; [email protected] > >> *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" <[email protected] <mailto: > [email protected]>> > >> *To:* Mike Jones <[email protected] <mailto: > [email protected]>>; "[email protected] <mailto:[email protected]>" < > [email protected] <mailto:[email protected]>> > >> *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:* [email protected] <mailto:[email protected]> [mailto: > [email protected]] <mailto:[mailto:[email protected]]> *On > Behalf Of *Mike Jones > >> *Sent:* Friday, 30 September 2011 4:53 AM > >> *To:* [email protected] <mailto:[email protected]> > >> *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 > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > **** > > ** ** > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
