Re: [OAUTH-WG] Possible alternative resolution to issue 26

I meant 3 and C

-- Dick

On 2011-10-03, at 6:56 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 As editor, based upon James’ input, I’d like to expand the set of choices
for the working group to consider by adding the possibility of using JSON
string encodings for scope and error_description where the characters used
for the encoding are restricted to the set of 7-bit ASCII characters
compatible with the HTTPbis and RFC 2617 parameter syntaxes.

1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.

3.  Using JSON string encoding for the scope parameter.

A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.

C.  Using JSON string encoding for the error_description parameter.

As an individual, I’m sympathetic to the argument that RFC 5987 (with
“scope*” and language tags etc.) is overkill for OAuth implementations,
where neither of the sets of strings is intended to be presented to
end-users.  Hence, the possible attractiveness of options 3 and C.

Thoughts from others?

                                                                -- Mike

*From:* William Mills [mailto:wmills@yahoo-inc.com]
*Sent:* Sunday, October 02, 2011 11:01 PM
*To:* Manger, James H; Mike Jones; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26

I don't like dropping scope from the WWW-Authenticate responses, because my
current discovery usage requires scope to be returned so that it can be
passed to the auth server if the user is forced to re-authenticate.

+1 for "explicitly restrict scope values to some subset of printable ASCII
in OAuth2 Core. Not being able to support Unicode in a new protocol is
slightly disappointing, but I can live with it."

   ------------------------------

*From:* "Manger, James H" <James.H.Manger@team.telstra.com>
*To:* Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org" <
oauth@ietf.org>
*Sent:* Sunday, October 2, 2011 5:50 AM
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26

The best solution is to drop the “scope” field from the “WWW-Authenticate:
Bearer ...” response header. “scope” is relevant to an OAuth2-core flow, not
to presenting a bearer token. “scope” could make sense in a
“WWW-Authenticate: OAuth2 ...” response header as long as other necessary
details such as an authorization URI were also provided. Dropping “scope”
and “error_description” (as the error should be described in the response
body) would eliminate these encoding problems.

If the group really wants to keep “scope”, I don’t think RFC 5987 is a good
solution. RFC 5987 might have been ok for adding internationalization
support to long-standing ASCII-only fields in a world of multiple character
sets – but none of that applies here. Having to change the field name from
“scope” to “scope*” when you have a non-ASCII value is the biggest flaw.

The simplest solution is to explicitly restrict scope values to some subset
of printable ASCII in OAuth2 Core. Not being able to support Unicode in a
new protocol is slightly disappointing, but I can live with it.

My preferred escaping solution would be a JSON string, UTF-8 encoded:
json.org, RFC 4627; value in double-quotes; slash is the escape char;
supports Unicode; eg scope="coll\u00E8gues". This is backward-compatible
with HTTP’s quoted-string syntax. It is forward-compatible with UTF-8 HTTP
headers (if that occurs). JSON is well-supported (and required for other
OAuth2 exchanges). [I might suggest json-string to the httpbis group as a
global replacement for quoted-string (or at least as a recommendation for
new fields).]

--

James Manger

*From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf Of
*Mike Jones
*Sent:* Friday, 30 September 2011 4:53 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Possible alternative resolution to issue 26

There seems to now be more working group interest in representing non-ASCII
characters in scope strings than had previously been in evidence.  If we
decide to define a standard representation for doing so, using RFC
5987<http://tools.ietf.org/html/rfc5987>(Character Set and Language
Encoding for Hypertext Transfer Protocol (HTTP)
Header Field Parameters) seems to be the clear choice.  I’d be interested in
knowing how many working group members are in favor of either:

1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.

As a related issue, some working group members have objected to specifying
UTF-8 encoding of the error_description value, requesting the use of RFC
5987 encoding instead.  I’d also be interested in knowing how many working
group members are in favor of either:

A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.

(As editor, I would make the observation that if we choose RFC 5987 encoding
for either of these parameters, it would be logical to do so for the other
one as well.)

In the interest of finishing the specification in a way that meets
everyone’s needs,

                                                            -- Mike

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

   _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth