> -----Original Message----- > From: John Kemp [mailto:j...@jkemp.net] > Sent: Monday, April 19, 2010 2:59 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: 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?
Yes. Servers can use whatever they like. We can say the values are URIs (absolute or relative) - this allows short names but helps future interop or standard URI-based values. The client finds out what value(s) to request from documentation or a 401 challenge. > > 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? No. Realm is too limited for many use cases. For example: Resource A: scopes a and b Resource B: scopes b and c Resource C: scope b If you want to access B and C you need a token scoped for b and c. No way to express this with realm. > The scope doesn't have to match the base URI of the resource which the > client tried and got the 401 from? That's a security issue we need to address (when to trust the resource server and reuse an existing token). We need to figure it out either way. > > > > 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? A list. > > > > 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). Yes. That's for another parameter and/or discovery flow. > > 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?) Why? The server tells the client what scope is needed for each resource. It can be a single scope id or multiple. The client checks to see if it has an access token issued with that scope combination. If it doesn't it goes and request an access token, and includes the required scope in the request. We can also allow the server to tell the client what scope an issued token includes in the token reply. The client doesn't need to understand the internal structure of the scope identifiers. It just need to know what to ask for when trying to access an unfamiliar resource. No documentation is needed. Client: I want to get an address book record with the latest email to that person. Server: You need an access token scoped for "Contact" and "Email". Client: Can I get an access token for scope=contact,email? Server: Sure, here is an access token for scope=email,contact (order doesn't matter). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
