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 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Tuesday, 27 September 2011 5:03 AM To: Barry Leiba Cc: [email protected] Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 Sounds good to me. Are others good with this wording? -- Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Barry Leiba Sent: Saturday, September 24, 2011 6:33 AM To: Mike Jones Cc: [email protected] 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
