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

From: "Manger, James H" <[email-masked]>
Date: Sun, 2 Oct 2011 23:50:33 +1100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: [email-masked]
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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 2 Oct 2011 08:56:13 -0700

I agree with this analysis and its conclusions.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Sunday, October 02, 2011 5:51 AM
To: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Possible alternative resolution to issue 26

---

From: William Mills <[email-masked]>
Date: Sun, 2 Oct 2011 23:01:03 -0700 (PDT)

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" <[email-masked]>
To: Mike Jones <[email-masked]>; "[email-masked]" <[email-masked]>
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.

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:[email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, 30 September 2011 4:53 AM
To: [email-masked]
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 (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:

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:

 
In the interest of finishing the specification in a way that meets everyone’s needs,
                                                            -- Mike
 
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Tue, 4 Oct 2011 01:55:18 +0000

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:[email-masked]]
Sent: Sunday, October 02, 2011 11:01 PM
To: Manger, James H; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

+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" <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

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

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:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 3 Oct 2011 19:21:37 -0700

slight preference for 3 and E

-- Dick

On 2011-10-03, at 6:56 PM, Mike Jones <[email-masked]> 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.

B.  Continuing to specify UTF-8 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:[email-masked]]
*Sent:* Sunday, October 02, 2011 11:01 PM
*To:* Manger, James H; Mike Jones; [email-masked]
*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" <[email-masked]>
*To:* Mike Jones <[email-masked]>; "[email-masked]" <
[email-masked]>
*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:* [email-masked] [mailto:[email-masked]] *On Behalf Of
*Mike Jones
*Sent:* Friday, 30 September 2011 4:53 AM
*To:* [email-masked]
*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:

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:

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 3 Oct 2011 19:22:32 -0700

I meant 3 and C

-- Dick

Thoughts from others?

                                                                -- Mike

--

James Manger

                                                            -- Mike

---

From: William Mills <[email-masked]>
Date: Mon, 3 Oct 2011 21:58:35 -0700 (PDT)

You forgot:

4.  Restrict the character set for scope to the point where these issues all go away.

________________________________
From: Mike Jones <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Manger, James H" <[email-masked]>; William Mills <[email-masked]>
Sent: Monday, October 3, 2011 6:55 PM
Subject: RE: [OAUTH-WG] Possible alternative resolution to issue 26

 

 
Thoughts from others?
 
                                                                -- Mike
 
From:William Mills [mailto:[email-masked]] 
Sent: Sunday, October 02, 2011 11:01 PM
To: Manger, James H; Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

 
From:"Manger, James H" <[email-masked]>

 
 
--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Oct 2011 09:28:45 +0200

On 2011-10-04 03:55, Mike Jones 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.
>
> ...

How is RFC 5987 encoding overkill, and JSON is not?

Note that if you'd use the \u notation inside a quoted string, you need 
to escape the backslashes due to the quoted-string syntax; which is 
likely a new source of errors.

Best regards, Julian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 04 Oct 2011 09:01:37 -0700

> 4.  Restrict the character set for scope to the point where these 

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 <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Cc:* "Manger, James H" <[email-masked]>; William 
> Mills <[email-masked]>
> *Sent:* Monday, October 3, 2011 6:55 PM
> *Subject:* RE: [OAUTH-WG] Possible alternative resolution to issue 26
>
> “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
> 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" <[email-masked] 
> <mailto:[email-masked]>>
> *To:* Mike Jones <[email-masked] 
> <mailto:[email-masked]>>; "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 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.
> 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:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]> *On Behalf Of *Mike Jones
> *To:* [email-masked] <mailto:[email-masked]>
> 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 
> 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 
> (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.)
> [email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 4 Oct 2011 09:47:57 -0700

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
[email-masked]

On 2011-10-04, at 9:01 AM, Michael Thomas wrote:

> see header field data. But these are individual cases here, not a protocol-wide
> mandate.
> 
> Mike
> 
>> 
>> *Cc:* "Manger, James H" <[email-masked]>; William Mills <[email-masked]>
>> *From:* "Manger, James H" <[email-masked] <mailto:[email-masked]>>
>> *To:* Mike Jones <[email-masked] <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> 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:* [email-masked] <mailto:[email-masked]> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> *On Behalf Of *Mike Jones
>> 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:

---

From: William Mills <[email-masked]>
Date: Tue, 4 Oct 2011 09:58:07 -0700 (PDT)

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 <[email-masked]>
To: "[email-masked] WG" <[email-masked]>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Tue, 4 Oct 2011 10:18:33 -0700

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
[email-masked]

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Oct 2011 11:01:00 -0700

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 <[email-masked]> 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 <[email-masked]>
> *To:* "[email-masked] WG" <[email-masked]>
> *Sent:* Tuesday, October 4, 2011 9:47 AM
> 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?
>
> 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
> >> 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
> ASCII in OAuth2 Core. Not being able to support Unicode in a new protocol is
> >> *To:* Mike Jones <[email-masked] <mailto:
> [email-masked]>>; "[email-masked] <mailto:[email-masked]>" <
> [email-masked] <mailto:[email-masked]>>
> “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.
> good solution. RFC 5987 might have been ok for adding internationalization
> 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.
> json.org <http://json.org>, RFC 4627; value in double-quotes; slash is the
> escape char; supports Unicode; eg scope="coll\u00E8gues". This 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:* [email-masked] <mailto:[email-masked]> [mailto:
> [email-masked]] <mailto:[mailto:[email-masked]]> *On
> Behalf Of *Mike Jones
> 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
> 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:
> encoding for either of these parameters, it would be logical to do so for
> the other one as well.)

---

From: Mike Jones <[email-masked]>
Date: Tue, 4 Oct 2011 18:07:06 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Tuesday, October 04, 2011 11:01 AM
To: Phil Hunt
Cc: [email-masked] 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 <[email-masked]<mailto:[email-masked]>> wrote:
I very much agree with you there.  As I said, simple roles are best and are by far the primary case.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

________________________________
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 4, 2011 9:47 AM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2011-10-04, at 9:01 AM, Michael Thomas wrote:

>> *From:* Mike Jones <[email-masked]<mailto:[email-masked]>>
>> *To:* "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>> *Cc:* "Manger, James H" <[email-masked]<mailto:[email-masked]>>; William Mills <[email-masked]<mailto:[email-masked]>>
>> 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.
>> 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:[email-masked]<mailto:[email-masked]>]
>> *To:* Manger, James H; Mike Jones; [email-masked]<mailto:[email-masked]>
>> *From:* "Manger, James H" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> *To:* Mike Jones <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> 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:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> [mailto:[email-masked]<mailto:[email-masked]>] <mailto:[mailto:[email-masked]<mailto:[email-masked]>]> *On Behalf Of *Mike Jones
>> *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> 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:
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Oct 2011 11:38:48 -0700

On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <[email-masked]>wrote:

>  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.
>

Aren't these simple strings URIs? I think they are parsed as a URI with no
scheme and authority only a path.

Marius

> ****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Marius Scurtescu
> *Sent:* Tuesday, October 04, 2011 11:01 AM
> *To:* Phil Hunt
> *Cc:* [email-masked] WG
>
> *Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26****
>
> ** **
>
> strings, for some reason I though they are a list of URIs.****
>
> ** **
>
> URIs using percent encoding (back to square one).****
>
> ** **
>
> away. Any reason not to do that?****
>
> ** **
>
> Marius
>
> ****
>
> On Tue, Oct 4, 2011 at 10:18 AM, Phil Hunt <[email-masked]> 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****
>
> [email-masked]****
>
> ** **
>
> ** **
>
> ** **
>
> On 2011-10-04, at 9:58 AM, William Mills wrote:****
>
>
>
> ****
>
> sublte ways with using it for XML.****
>
> ** **
> ****
> ** **
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: John Kemp <[email-masked]>
Date: Tue, 4 Oct 2011 14:48:43 -0400

On Oct 4, 2011, at 2:38 PM, Marius Scurtescu wrote:

> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <[email-masked]> wrote:
> 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.
> 
> 
> Aren't these simple strings URIs? I think they are parsed as a URI with no scheme and authority only a path.

Is there a need to parse these things as URIs semantically-speaking? Why wouldn't we restrict the character set of scopes to be those possible in a URI, but not say they have to be URIs semantically? I'd hate to require them to actually be URIs...

- John

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Oct 2011 21:18:16 +0200

On 2011-10-04 20:38, Marius Scurtescu wrote:
> On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>

No, they are relative references: 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2>.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Oct 2011 13:03:09 -0700

> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2>.

Right, which in this case are path elements.

Marius

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 5 Oct 2011 07:08:31 +0800

On 2011-10-05 at 05:07:06, Mike Jones wrote:
> 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.

Constraining syntax to an ascii token OR a URI (relative reference) might work.  Anything with a colon can be interpreted as a URI; anything without better use a constrained set of characters.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Oct 2011 19:48:12 -0400

> Constraining syntax to an ascii token OR a URI (relative reference) might
> work.  Anything with a colon can be interpreted as a URI; anything without
> better use a constrained set of characters.

This sounds like a good compromise.  URI encoding is already specified
elsewhere, and then ASCII tokens can be limited as they already are,
with no encoding.

Are there any objections to this approach?

Barry

---

From: William Mills <[email-masked]>
Date: Tue, 4 Oct 2011 16:56:07 -0700 (PDT)

Allowing URI requires allowing % encoding, which is workable.  As far as the protocol goes URI is a form of space separated string and the protocol doesn't care.  URI doesn't include quote or qhitespace in the allowed characters so there's no problem there.

I agree that we'd have to write it such that  it's clear you don't have to use a URI.  Drawing from http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps the allowed charset becomes

scope = *( unreserved / reserved / pct-encoded )

with the clarification that a scope MAY take the form of a properly formatted URI.

-bill

________________________________
From: "Thomson, Martin" <[email-masked]>
To: Mike Jones <[email-masked]>; Marius Scurtescu <[email-masked]>; Phil Hunt <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Sent: Tuesday, October 4, 2011 4:08 PM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Oct 2011 09:25:30 +0200

On 2011-10-05 01:56, William Mills wrote:
> Allowing URI requires allowing % encoding, which is workable. As far as
> the protocol goes URI is a form of space separated string and the
> protocol doesn't care. URI doesn't include quote or qhitespace in the
> allowed characters so there's no problem there.
>
> I agree that we'd have to write it such that it's clear you don't have
> to use a URI. Drawing from
> http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps
> the allowed charset becomes
> ...

Note that RFC 2396 has been obsoleted by RFC 3986 a long time ago. Don't 
use it as base syntax.

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 5 Oct 2011 10:28:13 -0700

It should be much simpler than that. The v2 spec should simply limit the character set to printable ascii with special meaning for space. Beyond that, these are just ascii strings which can be URIs or anything else. If the server choose to use these strings with some internal meaning (i.e. URI or encoded data), it should specify how normalization may occure.

But the point is, these are meant to be opaque, space-delimited string. Any interop beyond that requires additional specification (e.g. comma delimited inner string values, etc.).

It would be really helpful if people provide actual use cases and requirements. Everything I have seen so far will work just fine with a limited ascii set.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Tuesday, October 04, 2011 4:56 PM
To: Thomson, Martin; Mike Jones; Marius Scurtescu; Phil Hunt
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

________________________________
From: "Thomson, Martin" <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 4, 2011 4:08 PM
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

---

From: William Mills <[email-masked]>
Date: Wed, 5 Oct 2011 10:42:06 -0700 (PDT)

Are quotes a problem?  I think it's simpler if we leave them out.

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: William Mills <[email-masked]>; "Thomson, Martin" <[email-masked]>; Mike Jones <[email-masked]>; Marius Scurtescu <[email-masked]>; Phil Hunt <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Sent: Wednesday, October 5, 2011 10:28 AM
Subject: RE: [OAUTH-WG] Possible alternative resolution to issue 26

 
 
EHL
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Tuesday, October 04, 2011 4:56 PM
To: Thomson, Martin; Mike Jones; Marius Scurtescu; Phil Hunt
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

 

From:"Thomson, Martin" <[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 09:01:18 +0000

Introducing URI semantics for scope values containing colons seems like unnecessary and unmotivated invention at this point.  In the core spec, scope values are case-sensitive strings separated by spaces.  That's it.  Nothing about URIs or colons.  I believe that the scope semantics of the core and bearer specs should be consistent; this would not be.

Writing as an individual working group member...
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Tuesday, October 04, 2011 4:48 PM
To: Thomson, Martin
Cc: Mike Jones; Marius Scurtescu; Phil Hunt; [email-masked] WG
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

>> 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.
>
> Constraining syntax to an ascii token OR a URI (relative reference) 
> might work.  Anything with a colon can be interpreted as a URI; 
> anything without better use a constrained set of characters.

This sounds like a good compromise.  URI encoding is already specified elsewhere, and then ASCII tokens can be limited as they already are, with no encoding.

Barry

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 09:17:51 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, October 03, 2011 6:55 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26

Thoughts from others?

                                                                -- Mike

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Oct 2011 11:32:16 +0200

On 2011-10-07 11:17, Mike Jones wrote:
> 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.

Option 3 has a serious flaw in that it requires escaping the "\" in 
"\uNNNN", because it is the escape character in quoted-string. I think 
it's certain that people will be confused by that, and interop problems 
will happen (unless you have a strong test suite).

I do support 1; I just didn't repeat what I said before.

> 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.

See above.

Best regards, Julian

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 8 Oct 2011 01:15:53 +1100

> will happen (unless you have a strong test suite).

No, the "\" in "\uNNNN" would not be escaped.
The intention with adopting json-string would be to *replace* quoted-string.

I suggested this was ok as json-string is backward compatible
with quoted-string. That is not strictly true.
While json-string decodes "\u00E8" to a single char "è",
quoted-string decodes it to the 5 chars "u00E8".

This clash, however, may only be theoretical.
It is totally pointless to escape "u" as "\u" in a
quoted-string. I can confidently say it will never
have been done legitimately. If it does occurs in the wild,
99% of cases will be because the sender forgot to escape
the slash; and 99% of the remaining 1% will be because
a malicious sender is trying to bypass a security check by
escaping a char that the software never anticipated would
be escaped.

Quoted-string allows 93 ASCII chars to be used as themselves,
and defines an escaping mechanism to add 2 more chars:
double-quote and backslash (the escape char itself).
An escape mechanism to support the last ASCII visible char
might have been useful in an ASCII world, but it is pointless
today if it doesn't allow the other 100,000 Unicode chars.

If we specify json-string for a field specified elsewhere as
quoted-string I suspect we will get lucky and solve our Unicode
issue without causing any actual problems. That is partly
because I don't think most/many OAuth HTTP clients use
frameworks that automatically decode quoted-string values
in their bowels. Do others who write HTTP clients have
experience to the contrary?

I prefer option 3 (of the 3), perhaps with a note in the
spec saying: "Specifying json-string is a wilful violation
of RFC 2617 that uses quoted-string. It is done to
add support for Unicode values while supporting all valid
quoted-string values that occur in practise."

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Oct 2011 16:30:33 +0200

> The intention with adopting json-string would be to *replace* quoted-string.

You can't "replace" quoted-string.

A recipient will have to be able to parse multiple challenges in a 
single header field value. To do so, it has to understand the syntax of 
params using double quotes. It can't special-case the parsing based on 
what part of the set of challenges it currently is looking at (because 
to do so, it needs to have parsed them first).

> quoted-string decodes it to the 5 chars "u00E8".

Indeed.

> escaping a char that the software never anticipated would

But that's how quoted-string is defined, and what a conforming parser 
will do.

If your suggestion is to change that, you will have to bring that up in 
the HTTPbis WG, not here.

> today if it doesn't allow the other 100,000 Unicode chars.

But that argument doesn't change the fact how it is defined.

If we were free to change things, we'd simply state that everything is 
UTF-8.

> experience to the contrary?

As I said above: a recipient needs to parse header field values that 
contain multiple challenges, and changing the syntax for "quoted-string" 
based on where the param appears is simply a non-starter.

> quoted-string values that occur in practise."

Yes, it would be a willful intentional violation, without - IMHO - a 
strong technical argument to do so. I sure hope the IESG wouldn't accept 
that.

Best regards, Julian

---

From: William Mills <[email-masked]>
Date: Fri, 7 Oct 2011 09:34:33 -0700 (PDT)

after re-reading I'm for #2

Sent: Friday, October 7, 2011 2:17 AM

 

                                                            Thanks,
                                                            -- Mike

 

 
Thoughts from others?
 
                                                                -- Mike

 

 

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 10 Oct 2011 10:08:59 +1100

> to do so, it needs to have parsed them first).

Parsing is not affected. Only un-escaping after parsing.

Even if you did generic un-escaping before reaching code that
understood a specific parameter (and I'm not sure that is likely),
you still don't need to special-case the un-escaping. You can interpret it
all like JSON as no quoted-string value in practise will escape an
alphabetic letter (a-z). Not only would it be pointless for the sender to
do so, they would also be violating a "SHOULD NOT" in the spec.

   Senders SHOULD NOT escape octets in quoted-strings that do not
   require escaping (i.e., other than DQUOTE and the backslash octet).
   [draft-ietf-httpbis-p1-messaging-16#section-3.2.3]

> If we were free to change things, we'd simply state that everything is 

But that would break things.
I am only suggesting changing the interpretation of \u because
I don't believe it will break any existing values.

> But that argument doesn't change the fact how it is defined.

Changing defined behaviour is not great.
Changing defined behaviour that is *never used* (eg "\u" as an
escape sequence for "u") doesn't sound so unreasonable.

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Oct 2011 08:30:05 +0200

> understood a specific parameter (and I'm not sure that is likely),

It is possible. There is code out there that does it.

>     [draft-ietf-httpbis-p1-messaging-16#section-3.2.3]

It still is a violation of the spec if you do so.

> escape sequence for "u") doesn't sound so unreasonable.

Again, if you believe this is a good idea, the place to argue this is 
the HTTPbis WG, and not inventing something specific for OAuth.

Best regards, Julian