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

[Barry Leiba <[e-mail]>]

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 <[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