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

[Brian Campbell <[e-mail]>]

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

On Wed, Sep 28, 2011 at 10:36 AM, Marius Scurtescu
<[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>