Re: [OAUTH-WG] Scope - Coming to a Consensus

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Manger, James H
> Sent: Monday, May 03, 2010 6:24 AM
> To: OAuth WG ([e-mail])
> Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
> 
> A comma is a better separator here.
> Allow URIs as scopes -- as long as the chosen URIs don't have commas. This
> isn't a big restriction on services.

It's an odd restriction that violated the server's name space.

> [If a service provider really needs to include arbitrary URIs in an authorization
> URI they can still do so by defining another parameter, say "urls". We are
> barely defining any semantics for "scope" -- at least none that libraries can
> use -- so not much is lost in using a different parameter name.]

All this just to use a comma separator?
 
> A space-separated list (encoded as per the transport) sounds nice at a logical
> level, but is just a bit unnecessarily awkward. The only place scope values
> appear is in an authz URI so the only encoding is URI-encoding. Are the
> spaces escaped as "%20" or "+"? Even if we try to pick one answer I suspect
> both will occur (it depends on which part of the software builds the authz URI
> -- ie prepare for interop glitches).
> Any spaces in a URI used as a scope value needs to be %-escaped twice. It
> seems unnecessary to even allow this.

They would have to be encoded twice either way. Form-encoded query (according to the HTML 4 specification) allows only '.', '_', '-', and '~' to remain unencoded. Everything else must be encoded including a comma. The fact that you can send a comma in the query doesn't make it a valid way to transmit form-encoded parameters.

EHL