Subject: Re: [OAUTH-WG] Proposed resolution for issue 26

From: Mark Lentczner <[email-masked]>
Date: Tue, 4 Oct 2011 16:52:35 -0700

I think James has made the case that there is an issue clear.

As for what to pick, I favor not restricting scopes in the core spec, and
clearly specifying the way scopes will be presented in HTTP headers in the
bearer spec.

For the later, James supplies a nice list of the alternatives. Personally, I
think the URI-escaping is least likely to trip developers up. One must be
aware, though, that if there is only one scope string to provide, and it
meets the token production, then the scope needn't be in quotes.

I believe RFC 5987 is vast over-kill in this case. We have no need to enable
multiple different encodings, nor multiple encodings with a single header.
Further, I wonder how widespread support for it is in various HTTP
frameworks.

  - Mark

---

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

On 2011-10-05 01:52, Mark Lentczner wrote:
> As for what to pick, I favor not restricting scopes in the core spec,
> and clearly specifying the way scopes will be presented in HTTP headers
> in the bearer spec.
>
> For the later, James supplies a nice list of the alternatives.
> Personally, I think the URI-escaping is least likely to trip developers
> up. One must be aware, though, that if there is only one scope string to
> provide, and it meets the token production, then the scope needn't be in
> quotes.
>
> I believe RFC 5987 is vast over-kill in this case. We have no need to
> enable multiple different encodings, nor multiple encodings with a
> single header. Further, I wonder how widespread support for it is in
> various HTTP frameworks.

To answer that: RFC 5987 requires recipients to support UTF-8 and 
ISO-8859-1: so *two* encoding schemes. RFC 5987bis which is currently 
under discussion restricts this further to UTF-8.

HTTP frameworks that support Content-Disposition properly should have 
support for it. I'm not saying that many do right now, but the number is 
growing.

Format-wise: the value field is the same as for URI encoding, except 
that it adds a prefix specifying the encoding (and the optional 
language). It's dead easy to parse as you can just split on single 
quotes, take the first as encoding name and the third as URI-encoded value.

Finally, "just" specifying URI encoding still requires that people are 
told which encoding to use before percent encoding. In RFC 5987 this is 
explicit on the wire. If you do just URI encoding there's always the 
risk that people don't "get" it and just use what seems simple and works 
for ASCII (for instance, String.getBytes() without encoding parameter).

Best regards, Julian

---

From: Justin Richer <[email-masked]>
Date: Wed, 5 Oct 2011 08:46:50 -0400

+1

I would also prefer to not restrict scope values but provide clear
encoding for places where transport is going to be an issue. This is
what we do with tokens, which show up in the same places. Am I missing
the reason we can't use the exact same rules (modulo the single space
character) that apply to tokens? 

 -- Justin

On Tue, 2011-10-04 at 19:52 -0400, Mark Lentczner wrote:
> and clearly specifying the way scopes will be presented in HTTP
> headers in the bearer spec.
> 
> 
> Personally, I think the URI-escaping is least likely to trip
> developers up. One must be aware, though, that if there is only one
> scope string to provide, and it meets the token production, then the
> scope needn't be in quotes.
> 
>

---

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

On 2011-09-28 05:50, Manger, James H wrote:
> I'll have another go trying to explain the problem I see with the scope parameter in the Bearer spec.
>
> Consider a French social network that decides to offer an API using OAuth2. It chooses 3 scope values for parts of the API related to family, friends, and business colleagues:
> * "famille"
> * "ami"
> * "collègues"
> Let's focus on the last scope.
>
> The site describes the scope and its semantics in HTML developer docs. That works.
>    <dt>coll&#xE8;gues</dt><dd>...</dd>
>
> Client apps construct authorization URIs to which users are sent. That works.
>    https://example.fr/authz?scope=coll%C3%A8gues...
> ...

Wait a minute. This only works if the spec explicitly states that 
non-ASCII characters need to be UTF-8 encoded before escaping (this is 
not part of "application/x-www-form-urlencoded".

Best regards, Julian