Re: [OAUTH-WG] Issue: Scope parameter

[Justin Smith <[e-mail]>]

It isn’t clear to me how those options are better for interop than a scope parameter in the token request.

Also, the proposal forces the protected resource to know the context of the request and respond with the appropriate URI. This simply won’t work in many situations. For example, let’s say foo.com and bar.com may be bundled and available individualy. A client might need one access token that grants permission to both resources, another client might only get an access token that grants permission to one resource. With the proposal below, foo.com can’t respond with the correct value in the 401 (should the URI reference the individual service or the bundle).


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

> 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?


Foo.com should point the client at, say, http://as.com/foo/ or http://foo.as.com/ or http://as.com/?scope=foo or http://as.com/?encrypted_resource_id=273648264287642 or whatever it has agreed to with its AS.
The WWW-Auth response from foo.com should not be just http://as.com.
Foo is much better placed to know it shares as.com with Bar than a client is.

--
James Manger