+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
mscurte...@google.com wrote:
On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba barryle...@computer.org
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 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.
dtcoll#xE8;gues/dtdd.../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=collE8gues,
error_description=opps...
Another server sees that error_description is specified as UTF-8 so uses
that.
WWW-Authenticate: Bearer scope=collC3A8gues,
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
