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

> -----Original Message-----
> From: Luke Shepard [mailto:lshepard@facebook.com]
> Sent: Monday, April 19, 2010 10:21 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: 'Scope' parameter proposal
> 
> This seems pretty elegant to me. I like that in the general case, the protected
> resource can give an error saying the scope required.
> 
> As a specific example of how Facebook could use this, we have an extended
> permission for an app to publish to a user's stream. If an app tries to publish
> to the stream today, and they don't have the permission, we give an error
> that says "You need the publish_stream permission." With this extension, we
> could also add a header like:
> 
> WWW-Authenticate: Token realm="http://www.facebook.com",
> scope="publish_stream"
> 
> Then client libraries could craft an OAuth authorize URL for that scope,
> without having to refer to documentation.
> 
> One issue is how this would work with more complicated scenarios. There
> are resources that require multiple scopes, or even one of a few possible
> scopes (i.e., either "publish_stream" or "add_photo" to post a photo story).
> What are the semantics of the response header listing multiple scopes - are
> they all required, or just some?

The more complex the endpoint scope is, the more complex the "scope discovery" becomes. The trick is keeping the simple cases simple.

I would suggest this:

- If an endpoint requires a single or a set of scope identifiers, is uses a single WWW-Authenticate header with a scope parameter listing all the required values. They are all required (i.e. you need a token that covers them all). Anything else will not work.

- If an endpoint requires different sets of scope identifiers for different parameters or parameter values, it should reply with the required scope for the *failed* request only. It should help the client make the specific request it was attempting, not provide generic documentation for the entire endpoint capabilities.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Monday, April 19, 2010 9:25 AM
> To: OAuth WG
> Subject: [OAUTH-WG] 'Scope' parameter proposal
> 
> Proposal:
> 
> 'scope' is defined as a comma-separated list of resource URIs or resource
> groups (e.g. contacts, photos). 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'
> 
> 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.
> 
> That's it!
> 
> It allows the client to figure out what value to put in the scope parameter 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.
> 
> 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