I'd also like to see more working group participation in this discussion.
Thanks,
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry
Leiba
Sent: Wednesday, September 28, 2011 6:40 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
