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? -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
