I know we will control scope server side based on the calling client I can see why others may want to have a scope parameter though to allow a client app to decrease the scope they request (assuming short duration access), e.g. client app is entitled to request contacts and files based on their client identifier but they only request contacts for some operation, and the user feels more secure. Is this the main reason for scope?
James, how does your proposal work if the client needs access to more than one set of resources? Mark McGloin "Manger, James H" <james.h.man...@t eam.telstra.com> Sent by: oauth-boun...@iet f.org 16/04/2010 05:43 > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth