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
-----Original Message-----
From: Manger, James H [mailto:james.h.man...@team.telstra.com]
Sent: Saturday, September 24, 2011 7:41 AM
To: Mike Jones; oauth@ietf.org
Subject: RE: Proposed resolution for issue 26
> From: Mike Jones
>
> Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether the
> semantics of scope strings should be changed to require that the % character
> be interpreted as introducing a percent-encoded character that follows. My
> proposed resolution is that %-encoding not be required in the specification;
> therefore no textual change would be made to the specification in response to
> this issue. The reasoning behind this resolution is as follows:
I disagree. This does not resolve the ambiguity. I think there is some
confusion between 1) the internal structure (eg encoding) of a scope string,
and 2) escaping done when transporting the scope string in a protocol element.
> 1. Interpretation of scope strings already 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 particularly
> deployment context, it is reasonable for participants to have agreed upon
> that encoding, just as they agree on other OAuth configuration parameters.
A client app does NOT always need semantic agreement on the meaning of scope
strings.
Consider a client app that makes a request to a server and gets a 401 response
with 'WWW-Authenticate: Bearer ... scope="XXXXX"'. The client app now knows it
can run an OAuth exchange to get the required permission to retry the request,
and it should ask for the given scope during that OAuth exchange.
The client app needs to copy XXXXXX from the response header into an OAuth
exchange. It does not need to know anything more "semantics" about this scope
value. XXXXXXX can be opaque to the client app. The client app does need to
know any decode/encode steps involved in transferring this HTTP Bearer response
value to an OAuth exchange value.
If "XXXXXXX" is "1%2A2", should the client app redirect the user to
https://example.org/authz?scope=1%2A2&;...
or
https://example.org/authz?scope=1%252A2&;...
(or can the answer vary between different servers!!)
> 2. More than one encoding methodology could reasonably be employed in scope
> strings. For instance, base64url encoding of scope values could be used in
> some contexts. Quoting characters with '\' is another possibility. I see no
> compelling reason to mandate %-encoding over other potential encoding methods.
Servers can choose any encoding they want (including none) when defining their
own scope values (as logical Unicode strings).
That is a separate choice to the encoding that is used in the HTTP Bearer
response header when transporting a scope value.
> 3. Mandating %-encoding unnecessarily complicates implementations without
> providing a clear compensating benefit sufficient warrant the additional
> complexity. For example, it seems unnecessary to mandate that the scope
> strings "email" and "%65mail" MUST compare as being equal in all
> implementations.
When the scope string "email" is transported in JSON the receiver MUST compare
"\u0065mail" as equal. When it is transported as a URI query parameter the
receiver MUST compare "%65mail" as equal. This is normal JSON and query
parameter processing.
> 4. If an encoding methodology for scope strings is mandated, this should be
> done in the OAuth Core specification - not the OAuth Bearer Token
> specification.
The core spec implies that a scope value can consist of any Unicode characters
except space.
The core spec transports scope values in JSON or url-encoded fields that have
well-defined escaping mechanisms that are sufficient to handle all Unicode
string, hence all possible scope values.
The Bearer spec transports scope values in an HTTP response header parameter.
It defines no escaping mechanism so it cannot handle all Unicode strings (ie it
cannot handle all scope values that are possible in core).
It is strange for the Bearer spec to restrict scope values. It should leave
that to the core. Hence the Bearer spec should be able to transport any scope
value allowed in the core (ie any Unicode string). Hence an escaping mechanism
needs to be specified for the HTTP response header scope field.
> 5. I am aware of no existing practice that utilizes %-encoding of scope
> values.
Then a solution that avoids defining an escaping mechanism might work. It
requires the Bearer spec to explicitly say "The Bearer mechanism only works
with scope values that are limited to these ~90 ASCII characters (that can be
transported in an HTTP response header field without an escaping mechanism),
which is more restrictive than OAuth core". Or better still if you like this
approach, apply this restriction in core to all scope values.
--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
