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

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

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


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Tuesday, 27 September 2011 5:03 AM
To: Barry Leiba
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26

Sounds good to me.  Are others good with this wording?

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Saturday, September 24, 2011 6:33 AM
To: Mike Jones
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26

> My proposed resolution is that %-encoding not be required in the 
> specification

I agree with your analysis, now that I see it laid out clearly.  I would feel better, though, if there were text in the document that explained that to others, who read it later.  Perhaps, using your words, we could make this change to section 2.4:

OLD
   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The "scope" attribute MUST NOT appear more than
   once.

NEW
   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The "scope" attribute MUST NOT appear more than
   once.

   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.

Does that work?

Barry