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

["Manger, James H" <[e-mail]>]

> 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