I'd like to see more participation in this thread, besides just from Mike and James. What do others think?
Barry, as chair On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > While you take the viewpoint that the bearer spec is restricting scope > values, in fact, the spec intentionally allows all characters that can be > safely communicated in an HTTP response header parameter to be > used. About whether those characters employ an encoding > methodology to sometimes represent other characters or abstractions, > I believe that Barry's proposed wording hits the nail on the head: > > Interpretation of scope strings requires semantic agreement on the > meaning of the scope strings between the parties participating the > OAuth flow. Should an encoding be used for scope strings in a > particular deployment context, participants have to have agreed > upon that encoding, just as they agree on other OAuth configuration > parameters. > > Best wishes, > -- Mike On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: >> While you take the viewpoint that the bearer spec is restricting scope >> values, in fact, >> the spec intentionally allows all characters that can be safely communicated >> in an HTTP >> response header parameter to be used. > > But "all characters that can be safely communicated in an HTTP response > header parameter" is only a subset of the characters that OAuth Core > allows in a scope value (any Unicode string excluding space). I don't > understand how this isn't the Bearer spec restricting scope values. > > > P.S. You recognize here that non-ASCII chars cannot be safely > communicated in an HTTP response header parameter. This is why > Julian was concerned about the spec saying the error_description holds > raw UTF-8. > [Actually the ABNF for error_description restricts it to 93 ASCII chars so > when the text says it is UTF-8 encoded it is raising the potential problem > of arbitrary UTF-8 in HTTP headers unnecessarily.] > > -- > James Manger On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > I'll have another go trying to explain the problem I see with the scope > parameter in the Bearer spec. > > Consider a French social network that decides to offer an API using OAuth2. > It chooses 3 scope values for parts of the API related to family, friends, and > business colleagues: > * "famille" > * "ami" > * "collègues" > Let's focus on the last scope. > > The site describes the scope and its semantics in HTML developer docs. > That works. > <dt>collègues</dt><dd>...</dd> > > Client apps construct authorization URIs to which users are sent. > That works. > https://example.fr/authz?scope=coll%C3%A8gues... > > The authorization server issues credentials in a JSON token response. > That works. > { "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} > > The authorization server also supports implicit grants. That works. > Location: https://app.client.org/callback#scope=coll%C3%A8gues... > > Client apps request protected resources (without needing to mention scope). > That works. > Authorization: Bearer vF9dft4qmT > > A protected resource server responds with a 401 error when a bearer token > is wrong. They don't know what to put in the HTTP response header scope > parameter: "collègues" does not fit. > > One server knows HTTP headers have historically used ISO-8859-1. > WWW-Authenticate: Bearer scope="coll<E8>gues", error_description="opps"... > > Another server sees that error_description is specified as UTF-8 so uses that. > WWW-Authenticate: Bearer scope="coll<C3><A8>gues", > error_description="opps"... > > A third server reasons that the value will be copied to an authz URI so uses > URI-escaping. > WWW-Authenticate: Bearer scope="coll%C3%A8gues", error_description="opps"... > > A fourth server thinks JSON-escaping looks most like HTTP's quoted-string > quoting (both use '\'). > WWW-Authenticate: Bearer scope="coll\u00E8gues", error_description="opps"... > > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP Header > Field Parameters": > WWW-Authenticate: Bearer scope*=UTF-8''coll%C3%A8gues, > error_description="opps"... > > It is a total interoperability failure for the client apps. The paragraph in > the Bearer > spec saying the encoding of the scope values is up to each "particular > deployment context" looks like a cruel joke to the app and library developers. > > -- > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
