You are make my point. A scope parameter is useless without another vendor-specific spec in which case the vendor spec can define its own scope parameter. The argument of library support doesn't hold because libraries must pass any extension parameter anyway.
If people still want a scope parameter, they must define it in a way that it doesn't require vendor-specific knowledge. I am not sure this is possible or that useful. EHL On 4/16/10 8:25 AM, "Justin Smith" <justi...@microsoft.com> wrote: 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:james.h.man...@team.telstra.com] 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
