Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 15:42:58 +0000

Thanks for the useful discussion and the write-up, Hannes.  For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not generate objections during the IESG or IETF Last Call reviews.  A few additional comments...

1.  Error Description - Nothing to add to Hannes' write-up.

2.  Scope - I was planning to allow a broader set of ASCII characters than the "token" set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elements need to permit the full sets of "reserved" <http://tools.ietf.org/html/rfc3986#section-2.2> and "unreserved" <http://tools.ietf.org/html/rfc3986#section-2.3> characters in RFC 3986<http://tools.ietf.org/html/rfc3986>.  The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the "reserved" and "unreserved" sets.

3.  Authorization Request Header Field - We agreed on the call that we're not doing implementers any favors by allowing both the b64token and #auth-param syntaxes, and that it is better to specify one or the other.  Since existing practice corresponds to the b4token syntax, the choice is clear which to specify.  Thus, it was a mistake to introduce the #auth-param choice in draft 9.  It will be removed in draft 10, which is shortly forthcoming.

                                                            -- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi all,

I had a discussion with Mike and Julian to hear what to discuss the open issues with the OAuth Bearer Token draft. Below is a short writeup of my impressions.

1. Error Description

The error description field provides information to the software developer and is not meant to be shown to the end user. As such, there is no desire to provide internationalization support for this field. Hence, it has a similar characteristic as the HTTP 'Reason-Phrase.

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#reason.phrase says

"

The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the content of the Reason Phrase.

Reason-Phrase  = *( HTAB / SP / VCHAR / obs-text ) "

We can use something similar for the error description field and even simplify it further by omitting HTAB and obs-text:

  error-desc      = "error_description" "=" *( SP / VCHAR )

2. Scope

The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any internationalization support here either.

The suggestion is to re-use the 'token ABNF syntax from the HTTP spec:

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.3.2.3

3. Authorization Request Header Field

Finally, there is the authorization request header field where we have to decide how we want to deal with extensions.

The current specification says:

  credentials = "Bearer" 1*SP ( b64token / #auth-param )

This means that we can have either a base64 opaque blob or a parameter like syntax (but not both).

An example of the b64token is

Authorization: Bearer vF9dft4qmT

and an example of the auth-param usage is

Authorization: Bearer t=vF9dft4qmT

With an opaque blob extensibility is limited and for this reason, I guess, Mike had provided the additional option of auth-parameter.

If we want to allow extensibility then we have to go for the auth-param approach. If we only use the auth-param (without the b64token) then there may be an issue with already existing implementations. We will have to double-check.

Then, there is the possibility to provide two ways to encode the same information, namely either as a base64 blob and in the auth-parameter style. (In a single protocol run one would obviously only use one or the other.)

If we define the auth-param then we have to also provide information on what it actually is. We cannot leave that out of scope.

Ciao

Hannes

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Oct 2011 17:52:18 +0200

On 2011-10-14 17:42, Mike Jones wrote:
> Thanks for the useful discussion and the write-up, Hannes. For context,
> Hannes and I discussed how to resolve the remaining Bearer spec issues
> in a manner that meets the needs of implementations and will not
> generate objections during the IESG or IETF Last Call reviews. A few
> additional comments…
>
> 1. Error Description – Nothing to add to Hannes’ write-up.
>
> 2. Scope – I was planning to allow a broader set of ASCII characters
> than the “token” set, as these characters are inadequate for the use of
> URIs/URLs as scope elements. In particular, scope elements need to
> permit the full sets of “reserved”
> <http://tools.ietf.org/html/rfc3986#section-2.2>and “unreserved”
> <http://tools.ietf.org/html/rfc3986#section-2.3>characters in RFC 3986
> <http://tools.ietf.org/html/rfc3986>. The draft I am working on will say
> that scope is a space separated set of elements, where the elements
> consist of one or more characters from the union of the “reserved” and
> “unreserved” sets.
> ...

If you do that, you'll need to be careful with the encoding in case you 
stick with x-www-url-encoded (SP -> "+" etc).

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 14 Oct 2011 08:55:07 -0700

This is not sufficient.

For scope, if you are going to restrict the allowed characters, you must either specify how to encode all other values to fit the field, or we must move this restriction to the v2 specification so that no encoding is required.

For the token, you need to also define allowed token values so that they will fit in the header without encode, or specify an encoding scheme. The MAC token restricts token values (called MAC identifier) to %x20-21 / %x23-5B / %x5D-7E (any printable ASCII character except for " and \).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, October 14, 2011 8:43 AM
To: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi all,

1. Error Description

"

2. Scope

Ciao

Hannes

OAuth mailing list

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Oct 2011 18:10:39 +0200

> stick with x-www-url-encoded (SP -> "+" etc).

Sorry, /me confused.

Looked again at 
<https://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-09#section-2.4>:

    scope           = "scope" "=" <"> scope-v *( SP scope-v ) <">
    scope-v         = 1*quoted-char

    quoted-char     = ALPHA / DIGIT /
                      "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" /
                      "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" /
                      ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" /
                      "{" / "|" / "}" / "~" / "\" / "," / ";"

You can't do this, as it conflicts with the syntax for quoted-string.

So the right way to do this is to say:

   scope = "scope" *SP  "=" *SP ( token / quoted-string )

and then have prose constrain the value of the param after potentially 
unescaping the quoted-string.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 16:46:30 +0000

Indeed, recognizing that you're right that "you can't do that" with the current syntax, we decided to change scope to quoted-string so that it is compatible with HTTPbis and add the restriction that no "\" quoting may be present in the string (to simplify implementations).

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 9:11 AM
To: Mike Jones
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-14 17:52, Julian Reschke wrote:
>> Thanks for the useful discussion and the write-up, Hannes. For 
>> context, Hannes and I discussed how to resolve the remaining Bearer 
>> spec issues in a manner that meets the needs of implementations and 
>> will not generate objections during the IESG or IETF Last Call 
>> reviews. A few additional comments...
>>
>> 2. Scope - I was planning to allow a broader set of ASCII characters 
>> than the "token" set, as these characters are inadequate for the use 
>> of URIs/URLs as scope elements. In particular, scope elements need to 
>> permit the full sets of "reserved"
>> <http://tools.ietf.org/html/rfc3986#section-2.2>and "unreserved"
>> <http://tools.ietf.org/html/rfc3986#section-2.3>characters in RFC 
>> 3986 <http://tools.ietf.org/html/rfc3986>. The draft I am working on 
>> will say that scope is a space separated set of elements, where the 
>> elements consist of one or more characters from the union of the 
>> "reserved" and "unreserved" sets.
>> ...
>
> If you do that, you'll need to be careful with the encoding in case 
> you stick with x-www-url-encoded (SP -> "+" etc).

Sorry, /me confused.

Looked again at

and then have prose constrain the value of the param after potentially unescaping the quoted-string.

Best regards, Julian

---

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

Scope has to be defined in the core OAuth spec.  I think it's a mistake to talk about it in regard to the Bearer token spec specifically.

I think removing the auth-param usage is workable.  Then if we need extensibility defining a new scheme can do that.  It's a bit more work that way if needed, but it's clean.

-bill

________________________________
From: Mike Jones <[email-masked]>
To: Hannes Tschofenig <[email-masked]>; OAuth WG <[email-masked]>
Sent: Friday, October 14, 2011 8:42 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Thanks for the useful discussion and the write-up, Hannes.  For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not generate objections during the IESG or IETF Last Call reviews.  A few additional comments…

2.  Scope – I was planning to allow a broader set of ASCII characters than the “token” set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elements need to permit the full sets of “reserved” and “unreserved” characters in RFC 3986.  The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the “reserved” and “unreserved” sets.
 
3.  Authorization Request Header Field – We agreed on the call that we’re not doing implementers any favors by allowing both the b64token and #auth-param syntaxes, and that it is better to specify one or the other.  Since existing practice corresponds to the b4token syntax, the choice is clear which to specify.  Thus, it was a mistake to introduce the #auth-param choice in draft 9.  It will be removed in draft 10, which is shortly forthcoming.
 
                                                            -- Mike
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
 
Hi all, 

1. Error Description

 
"

 
 
2. Scope

 

 

 

 

 
Ciao
Hannes
 
[email-masked]
 
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 16:51:21 +0000

I am fine with this scope character set restriction also being added to the core spec.

As to your second comment, you'll find that the b64token definition<http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.1> already provides a character set restriction (as you suggest is needed).

                                                            -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Friday, October 14, 2011 8:55 AM
To: Mike Jones; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

This is not sufficient.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Friday, October 14, 2011 8:43 AM
To: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi all,

1. Error Description

"

2. Scope

Ciao

Hannes

OAuth mailing list

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Oct 2011 18:56:39 +0200

> Indeed, recognizing that you're right that "you can't do that" with the current syntax, we decided to change scope to quoted-string so that it is compatible with HTTPbis and add the restriction tha…

That's better, but I still believe that making up special rules is not 
productive. Just stick with the base syntax. If a "\" appears in a 
quoted-string, it means what it means, and recipients should be able to 
deal with it.

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 14 Oct 2011 10:24:26 -0700

Relying on b64token is not enough because you are only restricting the header syntax, not the other methods. Also, you are not restricting the server from issuing other values, in which case the client will need to figure out how to use the header with those values. My point is that you need to explicitly define the allowed range for tokens. Saying they must comply with the b64token rule is enough, just not enough to leave it implied via the header definition.

EHL

From: Mike Jones [mailto:[email-masked]]
Sent: Friday, October 14, 2011 9:51 AM
To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

                                                            -- Mike

From: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, October 14, 2011 8:55 AM
To: Mike Jones; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

This is not sufficient.

EHL

                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Hannes Tschofenig
Sent: Friday, October 14, 2011 5:25 AM
To: OAuth WG
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi all,

1. Error Description

"

2. Scope

Ciao

Hannes

OAuth mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Oct 2011 21:27:05 +0300

Hi Mike, 

> 2.  Scope – I was planning to allow a broader set of ASCII characters than the “token” set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elem…

Wouldn't it be more useful to say that you either want some plaintext values for the scope or URLs but not both?

Also, if you want to introduce "standardized" (or reserved values) then you have to 
a) specify them now (with no ability to change them), or 
b) prefix them.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 18:32:10 +0000

The core spec says "The strings are defined by the authorization server" (see http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3).  I don't see a reason to change that - especially this late in the game.  I am not introducing any standardized or reserved values.

My intent is not require or even suggest that scope values should be URIs.  My intent is to not preclude them from being so.

				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 11:27 AM
To: Mike Jones
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

On Oct 14, 2011, at 6:42 PM, Mike Jones wrote:

> 2.  Scope - I was planning to allow a broader set of ASCII characters than the "token" set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elements need to permit the full sets of "reserved" and "unreserved" characters in RFC 3986.  The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the "reserved" and "unreserved" sets.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Oct 2011 22:28:28 +0300

Hi Mike, 

what values do we want to support? 

We know that from the base specification we want a list of space-delimited, case sensitive strings.

We don't want support for internationalized character-sets. 

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Fri, 14 Oct 2011 19:40:29 +0000

Any strings that the Authorization Server chooses to define meanings for

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 12:28 PM
To: Mike Jones
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 15 Oct 2011 15:16:00 +0300

Hi Mike, 

this is not specific enough. A string could be defined as
"
A string is a sequence of zero or more Unicode characters [UNICODE].
"
(as in RFC 4627), or as
"
8-bit binary data without a NUL (hex 00) termination
"
(as in RADIUS, RFC 2865). 

In any case, we have to consider the constraints from the usage of
"application/x-www-form-urlencoded". In our specific case this means
that we have to get from the scope string to an octet sequence, which is
allowed by application/x-www-form-urlencoded.

Julian had pointed to this issue already (see mail from October 7th).

If you want any string (with the exception of SP, which is the
delimiter) then you have to choose an encoding that is able to represent
Unicode in ASCII. There are a few choices and according to Julian the
following options exist:

a) RFC 5987
b) URI encoding to UTF-8 encoding
(which is essentially like RFC 5987 but to omit the language part of the
triple)
c) JSON (with the problem that the "\" notation in the quoted-string)

If you want to go along this route then I would suggest to go for (a)
and to include a couple of examples (see Section 3.2.2 of RFC 5987 for
examples). This is clearly better than inventing a new mechanism
ourselves. The language tag is optional and RFC 5987 only requires
parser support for UTF-8 and ISO-8859-1. 

Ciao
Hannes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Mike Jones
Sent: Friday, October 14, 2011 10:40 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
Proposed Resolutions

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 12:28 PM
To: Mike Jones
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &
Proposed Resolutions

Hi Mike, 

We know that from the base specification we want a list of
space-delimited, case sensitive strings.

Ciao
Hannes

On Oct 14, 2011, at 9:32 PM, Mike Jones wrote:

> The core spec says "The strings are defined by the authorization
server" (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3).  I don't
see a reason to change that - especially this late in the game.  I am
not introducing any standardized or reserved values.
> 
> My intent is not require or even suggest that scope values should be
URIs.  My intent is to not preclude them from being so.
>> 2.  Scope - I was planning to allow a broader set of ASCII characters
than the "token" set, as these characters are inadequate for the use of
URIs/URLs as scope elements.  In particular, scope elements need to
permit the full sets of "reserved" and "unreserved" characters in RFC
3986.  The draft I am working on will say that scope is a space
separated set of elements, where the elements consist of one or more
characters from the union of the "reserved" and "unreserved" sets.
> 
> Wouldn't it be more useful to say that you either want some plaintext
values for the scope or URLs but not both?

---

From: Julian Reschke <[email-masked]>
Date: Sat, 15 Oct 2011 14:20:16 +0200

> (which is essentially like RFC 5987 but to omit the language part of the

Actually, omitting both the charset and the language part, and 
hardwiring the encoding to UTF-8.

> parser support for UTF-8 and ISO-8859-1.

...and for RFC5987bis we are discussing to restrict this to UTF-8 only...

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Sun, 16 Oct 2011 05:12:32 +0000

In your note yesterday summarizing our proposed issue resolutions, you wrote "The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any internationalization support here either."

I'm therefore confused by your note below, Hannes, as it seems to me to contradict both your statement above.  In particular, there's no need for Unicode encodings when internationalization isn't required.  ASCII characters are fine for representing machine-readable scope elements that will never be displayed to users.  That's the approach I'm taking in draft 10.  (And indeed, EVERY draft of the bearer token spec has specified only ASCII characters, so this is nothing new...)

				-- Mike

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]] 
Sent: Saturday, October 15, 2011 5:16 AM
To: Mike Jones; Hannes Tschofenig
Cc: OAuth WG
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

this is not specific enough. A string could be defined as "
A string is a sequence of zero or more Unicode characters [UNICODE].
"
(as in RFC 4627), or as
"
8-bit binary data without a NUL (hex 00) termination "
(as in RADIUS, RFC 2865). 

In any case, we have to consider the constraints from the usage of "application/x-www-form-urlencoded". In our specific case this means that we have to get from the scope string to an octet sequence, which is allowed by application/x-www-form-urlencoded.

If you want any string (with the exception of SP, which is the
delimiter) then you have to choose an encoding that is able to represent Unicode in ASCII. There are a few choices and according to Julian the following options exist:

a) RFC 5987

If you want to go along this route then I would suggest to go for (a) and to include a couple of examples (see Section 3.2.2 of RFC 5987 for examples). This is clearly better than inventing a new mechanism ourselves. The language tag is optional and RFC 5987 only requires parser support for UTF-8 and ISO-8859-1. 

Ciao
Hannes

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Friday, October 14, 2011 12:28 PM
To: Mike Jones
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Hi Mike, 

Ciao
Hannes

> The core spec says "The strings are defined by the authorization
server" (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3).  I don't see a reason to change that - especially this late in the game.  I am not introducing any standardized or reserved values.
Proposed Resolutions
>> 2.  Scope - I was planning to allow a broader set of ASCII characters
than the "token" set, as these characters are inadequate for the use of URIs/URLs as scope elements.  In particular, scope elements need to permit the full sets of "reserved" and "unreserved" characters in RFC 3986.  The draft I am working on will say that scope is a space separated set of elements, where the elements consist of one or more characters from the union of the "reserved" and "unreserved" sets.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Oct 2011 12:43:45 +0200

> I'm therefore confused by your note below, Hannes, as it seems to me to contradict both your statement above.  In particular, there's no need for Unicode encodings when internationalization isn't r…

Confused we are :-)

The core spec doesn't restrict what can be in a scope (looking at 
<https://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3>).

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Sun, 16 Oct 2011 16:44:34 +0000

As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs."

				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Sunday, October 16, 2011 3:44 AM
To: Mike Jones
Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-16 07:12, Mike Jones wrote:
> I'm therefore confused by your note below, Hannes, as it seems to me 
> to contradict both your statement above.  In particular, there's no 
> need for Unicode encodings when internationalization isn't required.  
> ASCII characters are fine for representing machine-readable scope 
> elements that will never be displayed to users.  That's the approach 
> I'm taking in draft 10.  (And indeed, EVERY draft of the bearer token 
> spec has specified only ASCII characters, so this is nothing new...)

Confused we are :-)

The core spec doesn't restrict what can be in a scope (looking at <https://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-3.3>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 Oct 2011 20:00:06 +0200

> As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs."

I see. Thanks.

Is this going to be clarified in -23?

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 16 Oct 2011 15:54:20 -0700

It's an open question for the list.

EHL

> Sent: Sunday, October 16, 2011 11:00 AM
> To: Mike Jones
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth WG;
> Eran Hammer-Lahav
> > As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of
> characters in scope was unintentional. The design was limited to allow simple
> ASCII strings and URIs."
> > ...
> 
> I see. Thanks.
>

---

From: John Bradley <[email-masked]>
Date: Sun, 16 Oct 2011 17:11:54 -0700

Restricting it now in the core spec is going to save a lot of headaches later.

John B.

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 17 Oct 2011 02:19:09 +0000

I think the limit makes sense, but then are tokens limited by the same rules? They need to live in all the same places (query parameters, headers, forms) that scopes do and would be subject to the same kinds of encoding woes that scopes will. Or am I missing something obvious as to why this isn't a problem for tokens (both bearer tokens and the public part of MAC tokens) but is a problem for scope strings?

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] on behalf of John Bradley [[email-masked]]
Sent: Sunday, October 16, 2011 8:11 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues &    Proposed Resolutions

John B.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Oct 2011 10:32:35 +0200

> It's an open question for the list.

Well, as long as it is not restricted in the core spec, the bearer spec 
will have to handle the case (or document this as known technical 
omission, I guess).

Best regards, Julian

---

From: John Bradley <[email-masked]>
Date: Mon, 17 Oct 2011 06:07:07 -0700

The scopes cross all of the profiles.

I expect that restricting the character sets for bearer tokens, MAC, and other future variants should be dealt with in those profiles. 

Without restricting scope in core, we leave the possibility of coming up with different rules in different profiles e.g. MAC vs Bearer.

It is probably best to have one rule in core that works across all the profiles.

John B.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 17 Oct 2011 07:27:20 -0700

I agree.

EHL

> From: John Bradley [mailto:[email-masked]]
> Sent: Monday, October 17, 2011 6:07 AM
> To: Richer, Justin P.
> Cc: Eran Hammer-Lahav; OAuth WG
> I expect that restricting the character sets for bearer tokens, MAC, and other
> future variants should be dealt with in those profiles.
> 
> Without restricting scope in core, we leave the possibility of coming up with
> different rules in different profiles e.g. MAC vs Bearer.
> 
> > I think the limit makes sense, but then are tokens limited by the same
> rules? They need to live in all the same places (query parameters, headers,
> forms) that scopes do and would be subject to the same kinds of encoding
> woes that scopes will. Or am I missing something obvious as to why this isn't
> a problem for tokens (both bearer tokens and the public part of MAC tokens)
> but is a problem for scope strings?
> >
> > -- Justin
> >>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; OAuth
> >>> WG; Eran Hammer-Lahav
> >>> characters in scope was unintentional. The design was limited to
> >>> allow simple ASCII strings and URIs."
> >>>> ...
> >>>
> >>> I see. Thanks.
> >>>

---

From: William Mills <[email-masked]>
Date: Mon, 17 Oct 2011 09:11:34 -0700 (PDT)

What's the current leaning in the core spec.  Is there a direction emerging for this answer?

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: John Bradley <[email-masked]>; "Richer, Justin P." <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Monday, October 17, 2011 7:27 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

I agree.

EHL

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Oct 2011 08:25:24 -0700

It is good that we have an agreement among a few people that more text needs to be provided in the core specification on the issue of the scope element. 

Now, there is still the question of what the text should say. The questions from my earlier mails are therefore still applicable and need an answer. 

Ciao
Hannes

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 17 Oct 2011 11:53:43 -0700

All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.

EHL

> Sent: Monday, October 17, 2011 8:25 AM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; John Bradley; Richer, Justin P.; OAuth WG
> It is good that we have an agreement among a few people that more text
> needs to be provided in the core specification on the issue of the scope
> element.
> 
> Now, there is still the question of what the text should say. The questions
> from my earlier mails are therefore still applicable and need an answer.
> 
> Ciao
> Hannes
> 
> >> I expect that restricting the character sets for bearer tokens, MAC,
> >> and other future variants should be dealt with in those profiles.
> >>
> >> Without restricting scope in core, we leave the possibility of coming
> >> up with different rules in different profiles e.g. MAC vs Bearer.
> >>
> >> forms) that scopes do and would be subject to the same kinds of
> >> encoding woes that scopes will. Or am I missing something obvious as
> >> to why this isn't a problem for tokens (both bearer tokens and the
> >> public part of MAC tokens) but is a problem for scope strings?
> >>>
> >>> -- Justin

---

From: John Bradley <[email-masked]>
Date: Mon, 17 Oct 2011 12:13:28 -0700

+1

---

From: William Mills <[email-masked]>
Date: Mon, 17 Oct 2011 13:53:17 -0700 (PDT)

+1

________________________________
From: John Bradley <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Monday, October 17, 2011 12:13 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

---

From: Mike Jones <[email-masked]>
Date: Mon, 17 Oct 2011 22:25:26 +0000

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Monday, October 17, 2011 1:53 PM
To: John Bradley; Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

________________________________
From: John Bradley <[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
Sent: Monday, October 17, 2011 12:13 PM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1

On 2011-10-17, at 11:53 AM, Eran Hammer-Lahav wrote:

>> From: Hannes Tschofenig [mailto:[email-masked]<mailto:[email-masked]>]
>>>> From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of
>>>>> John Bradley [[email-masked]<mailto:[email-masked]>]
>>>>>>> From: Julian Reschke [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Phil Hunt <[email-masked]>
Date: Mon, 17 Oct 2011 15:40:04 -0700

+1

Phil

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Oct 2011 15:50:12 +0200

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.

You also need to have one character reserved as delimiter for multiple 
scopes inside quoted-string, so is SP out?

Best regards, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 18 Oct 2011 08:38:13 -0700

Space is allowed inside a quoted string and is already not allowed inside each scope string.

EHL

> Sent: Tuesday, October 18, 2011 6:50 AM
> To: Eran Hammer-Lahav
> > All I agree with is to limit the scope character-set in the v2 spec to the
> subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no
> escaping is needed, ever.
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Oct 2011 18:39:54 +0200

> Space is allowed inside a quoted string and is already not allowed inside each scope string.

a) yes.

b) well:

    The value of the scope parameter is expressed as a list of space-
    delimited, case sensitive strings.  The strings are defined by the
    authorization server.  If the value contains multiple space-delimited
    strings, their order does not matter, and each string adds an
    additional access range to the requested scope.

That certainly implies that you can't have a space inside a token, but 
it could be clearer.

Optimally, state the character repertoire precisely:

   scopetokenchar =  %x21 / %x23-5B / %x5D-7E
   ; HTTPbis P1 qdtext except whitespace, restricted to US-ASCII

?

Best regards, Julian

---

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

Anyone objecting here?

________________________________
From: Mike Jones <[email-masked]>
To: William Mills <[email-masked]>; John Bradley <[email-masked]>; Eran Hammer-Lahav <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Monday, October 17, 2011 3:25 PM
Subject: RE: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

+1
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Monday, October 17, 2011 1:53 PM
To: John Bradley; Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions
 
+1

From:John Bradley <[email-masked]>

+1

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 19 Oct 2011 10:23:54 -0700

Marius

On Tue, Oct 18, 2011 at 9:39 AM, Julian Reschke <[email-masked]> wrote:
> That certainly implies that you can't have a space inside a token, but it
> could be clearer.
>

Is this covering all characters allowed in a URI? Why not define
scopes as a list of URIs?

---

From: William Mills <[email-masked]>
Date: Wed, 19 Oct 2011 11:15:57 -0700 (PDT)

> Is this covering all characters allowed in a URI? Why 

> not definescopes as a list of URIs?

I'd rather not do this because people will presume unless we add even more text to explain it that they need to have the form scheme://host/path or some such.  It's an opportunity to bloat scopes far out of proportion to what is actually needed.

________________________________
From: Marius Scurtescu <[email-masked]>
To: Julian Reschke <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Wednesday, October 19, 2011 10:23 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 19 Oct 2011 11:23:51 -0700

On Wed, Oct 19, 2011 at 11:15 AM, William Mills <[email-masked]> wrote:
>> not define scopes as a list of URIs?
> I'd rather not do this because people will presume unless we add even more
> text to explain it that they need to have the form scheme://host/path or
> some such.

Which is not necessarily a bad thing. It allows systems to scale and
interoperate.

> It's an opportunity to bloat scopes far out of proportion to
> what is actually needed.
>

---

From: William Mills <[email-masked]>
Date: Wed, 19 Oct 2011 11:52:24 -0700 (PDT)

I'm not saying we should not make URIs valid scopes.  I'm saying that I think it's confusing and unnecessary to state that scopes are URIs.  I'd be much happier if we say "The definition of scope allows URIs to be used if needed." or some such.

________________________________
From: Marius Scurtescu <[email-masked]>
To: William Mills <[email-masked]>
Cc: Julian Reschke <[email-masked]>; OAuth WG <[email-masked]>
Sent: Wednesday, October 19, 2011 11:23 AM
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Oct 2011 11:03:42 +0200

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.

I noticed that this hasn't been done yet, but the bearer spec, for which 
publication was just requested, kind of assumes it *will* be done.

Are mechanisms in place to ensure that this change indeed happens?

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Oct 2011 14:10:11 +0000

Yes, this change is tracked in the issue tracker as issue #27: Incorporate bearer "scope" character restrictions into the base spec.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Friday, October 28, 2011 2:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

> All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever.

I noticed that this hasn't been done yet, but the bearer spec, for which publication was just requested, kind of assumes it *will* be done.

Best regards, Julian