Re: [OAUTH-WG] Issue: Scope parameter

[Justin Smith <[e-mail]>]

Great.

So, let’s say there is an Authorization Server available at http://as.com and it protects the http://foo.com and http://bar.com resources.

A client requests  http://foo.com. The foo.com server responds with a WWW-Auth that contains the http://as.com URI. The client then sends an access token request to http://as.com. Is that right?

If so, then how does http://as.com know that the intended resource is http://foo.com?

From: Manger, James H [mailto:[e-mail]]
Sent: Thursday, April 15, 2010 9:09 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter

> Is it important for an Authorization Server to be able to protect multiple resources?

YES

>  If so, how should the client specify which resource it intends to access (it seems like that is required)?

By redirecting the user to an authz URI that represents the intended resource.

If the client is interoperating with a resource it has no special knowledge about, then it can learn the authz URI from the 401 WWW-Auth.: OAUTH header it received when trying to access the resource directly. The server returning this header knows what resource the client asked for so the server can encode that information into the returned authz URI in whatever way it has prearranged with its AS.


--
James Manger


From: [e-mail] [mailto:[e-mail]] On Behalf Of Manger, James H
Sent: Thursday, April 15, 2010 6:40 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

> I don’t see how the presence of a scope parameter hurts interoperability.

Scopes so far have all been specific to a specific service. Knowing how Google uses ‘scope’ tells you nothing about interoperating with Microsoft.

Requesting access to specific sets of resources is important. However, you can do it by providing different user-authorization URIs — even if the URIs only differ in the value of a ‘scope’ query parameter.

For a library that isn’t service-specific, a scope value offers no semantic value. All the library can do is tack it onto a supplied user authz URI. In which case it is simpler for the library to just accept a user authz URI that has had the scope tacked on before being passed to the library.


--
James Manger

From: [e-mail] [mailto:[e-mail]] On Behalf Of Justin Smith
Sent: Friday, 16 April 2010 9:39 AM
To: Eran Hammer-Lahav; Marius Scurtescu; [e-mail]
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Scope parameter

I don’t see how the presence of a scope parameter hurts interoperability.

It think scope needs to be a 1st class citizen in the spec, not an extension. Without it, a client cannot request access to a specific set of resources (whether its represented as a string, URI, or anything else). Does the group think it Is important for an Authorization Server to be able to make auth decisions based on requested resources?