Re: [OAUTH-WG] 'Scope' parameter proposal

On Apr 19, 2010, at 12:25 PM, Eran Hammer-Lahav wrote:

> Proposal:
> 
> 'scope' is defined as a comma-separated list of resource URIs or resource
> groups (e.g. contacts, photos).

So, 'scope' at the authenticating (via OAuth) server is simply a list of one or more URIs? There are no defined, interoperable, semantics that a server should use here - is that correct?

> The server can provide a list of values for
> the client to use in its documentation, or the client can use the URIs or
> scope identifier of the protected resources it is trying to access (before
> or after getting a 401 response).
> 
> For example:
> 
> 1. Client requests resource
> 
>    GET /resource HTTP/1.1
>    Host: example.com
> 
> 2. Server requires authentication
> 
>    HTTP/1.1 401 Unauthorized
>    WWW-Authenticate: Token realm='Example', scope='x2'

No (implied or otherwise) relationship between the realm and the scope? 

The scope doesn't have to match the base URI of the resource which the client tried and got the 401 from?

> 
> 3. Client requests an access token by including scope=x2 in the request
> 
> Alternatively, the client can ask for an access token with
> scope=http://example.com/resource.
> 
> If the client needs access to two resource with different scopes, it
> requests an access token for scope=x2,x1.

Is the "effective" scope a URI, or a list of URIs?

> 
> That's it!
> 
> It allows the client to figure out what value to put in the scope parameter

It doesn't tell the client where to go to get a token related to that scope (nor should it). 

> and how to encode multiple scopes without any server-specific documentation.
> Servers that wish to rely exclusively on paperwork can just omit the scope
> parameter from the WWW-Authenticate header.

I think that there is much that is unspecified in this model and thus it doesn't provide much interoperability. If we don't tell the client what to do with the scope, and we don't specify what a server means by supplying a scope, I'm not sure what the point is to specifying this at all as clients will still need some documentation or be hard-coded (which token service do I get such a token from?) 

What am I missing here?

Cheers,

- johnk

> 
> We can pick a different separator (space, semicolon, etc.) or different
> parameter name (resource(s)).
> 
> EHL
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth