Re: [OAUTH-WG] Proposed resolution for issue 26

[Marius Scurtescu <[e-mail]>]

On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba <[e-mail]>wrote:

> I'd like to see more participation in this thread, besides just from
> Mike and James.  What do others think?
>

I think James made it pretty clear that we have a problem and that we have
to solve it.

One solution would be for the core spec to limit the characters that can be
used in a scope, such that scopes are HTTP header safe. I think this would
be pretty limiting and fragile.

Another solution would be for the bearer spec to specify what escaping
should be used. RFC 5987 seems like the only good choice.

Marius


> Barry, as chair
>
> On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones <[e-mail]>
> 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
> <[e-mail]> 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
> <[e-mail]> 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&#xE8;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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>