On 10/03/2011 09:58 PM, William Mills wrote:
You forgot:
4. Restrict the character set for scope to the point where these
issues all go away.
Assuming that this is *completely* internal, and no end users will ever
see either of these, this seems like the most prudent if interoperability
is the primary goal. The principle of least surprise, and all.
But completely internal is impossible to guarantee, so I guess the question
is whether an incomprehensible katakana-encoded message/token is any
worse than an incomprehensible ascii-7 english one to the poor end user
who's trying to make sense of it. If it isn't then keeping things simple is
probably safer. I assume the reason that 5987 exists is because as a
whole, http shouldn't make any assumptions about whether users will
see header field data. But these are individual cases here, not a
protocol-wide
mandate.
Mike
------------------------------------------------------------------------
*From:* Mike Jones <michael.jo...@microsoft.com>
*To:* "oauth@ietf.org" <oauth@ietf.org>
*Cc:* "Manger, James H" <james.h.man...@team.telstra.com>; William
Mills <wmi...@yahoo-inc.com>
*Sent:* Monday, October 3, 2011 6:55 PM
*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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
