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

[Marius Scurtescu <[e-mail]>]

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