Thus far, I believe those who have expressed opinions have been pretty evenly
split between 2 and 3 on the scope issue. I’ve seen no support for 1 since I
sent my request for opinions.
For the error_description issue, I’ve seen support for C, whereas I’ve heard
criticisms voiced against A and B, and have heard no support for either of them.
In the interest of resolving these issues, I’d appreciate it if others would
weigh in soon.
Thanks,
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, October 03, 2011 6:55 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
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:wmi...@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.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>>
To: Mike Jones
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>;
"oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto: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<http://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-boun...@ietf.org<mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On
Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: oauth@ietf.org<mailto: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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
