Existing practice is that simple ASCII strings like "email" "profile",
"openid", etc. are used as scope elements. Requiring them to be URIs would
break most existing practice.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Marius Scurtescu
Sent: Tuesday, October 04, 2011 11:01 AM
To: Phil Hunt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
I just realized that scopes are defined as a space separated list of strings,
for some reason I though they are a list of URIs.
Mark Lentczner just clarified for me that URIs are supposed to be ASCII only.
IRIs can have non-ASCII characters and can be canonically converted to URIs
using percent encoding (back to square one).
If the core spec defines scope as list of URIs then the whole issue goes away.
Any reason not to do that?
Marius
On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:
I very much agree with you there. As I said, simple roles are best and are by
far the primary case.
I'm just not so sure we should close the door.
Phil
@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
On 2011-10-04, at 9:58 AM, William Mills wrote:
I don't believe that scope is the right place to carry a more complex grant,
those would live in the token. That would more logically go in the token. XML
gets weird when you get to the part about space separationoand order doesn't
matter. Scope's current definition makes it incompatible in sublte ways with
using it for XML.
________________________________
From: Phil Hunt <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>
To: "oauth@ietf.org<mailto:oauth@ietf.org> WG"
<oauth@ietf.org<mailto:oauth@ietf.org>>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
In most cases, scope has just been a set of simple "roles" as in "readProfile",
"updateStatus", etc.
I tend to agree scope is an internal value that SHOULD never be seen by
end-users (this should be made clear). The meaning of a scope must be conveyed
in authorization dialog, the how of which is out of scope. Since the resource
server defines how it scopes information, it should be able to explain the
meaning of a scope request in localized language.
I'm not against encoding the value if necessary to handle non-printable
characters. The issue I think comes back to complexity for the clients. Would
such encoding be problematic for the clients envisioned?
Some examples I can think of:
* A URL to a specific resource
* An XML or JSON structure representing a more complex "grant" or policy
statement
Phil
@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
On 2011-10-04, at 9:01 AM, Michael Thomas wrote:
> 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<mailto:michael.jo...@microsoft.com>>
>> *To:* "oauth@ietf.org<mailto:oauth@ietf.org>"
>> <oauth@ietf.org<mailto:oauth@ietf.org>>
>> *Cc:* "Manger, James H"
>> <james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>>;
>> William Mills <wmi...@yahoo-inc.com<mailto: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<mailto:wmi...@yahoo-inc.com>]
>> *Sent:* Sunday, October 02, 2011 11:01 PM
>> *To:* Manger, James H; Mike Jones; oauth@ietf.org<mailto: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>
>> <mailto: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>
>> <mailto:michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>>;
>> "oauth@ietf.org<mailto:oauth@ietf.org>
>> <mailto:oauth@ietf.org<mailto:oauth@ietf.org>>"
>> <oauth@ietf.org<mailto:oauth@ietf.org>
>> <mailto: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> <http://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:oauth-boun...@ietf.org>>
>> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>]
>> <mailto:[mailto:oauth-boun...@ietf.org<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>
>> <mailto: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>
>> <mailto:OAuth@ietf.org<mailto:OAuth@ietf.org>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
