I agree with Dick that the scope should remain out of scope for OAuth. ;-) Having a shared parameter here gives the illusion of interoperability, but because there's no common understanding of permissible scopes, there's no way to guarantee that any given client-server pair could expect to produce predictable outcomes.
Furthermore, limiting the format of the scope prematurely means that we give up on a whole set of possibilities before we've even had a chance to see what those possibilities are. For example, YQL might want to allow a scope to be defined like "SELECT * FROM flickr" or something similar. Maybe scope is implicit in assertions, or even explicit. Scope might be tied to the degree to which the requesting and/or granting parties are trusted by the service provider. If there were a compelling story about how scope is supposed to realistically achieve greater interoperability, it might be worthwhile for us to consider it. In the meantime, though, I think it just represents the same featuritis drive that got us an under-specified (and more harmful than helpful) version parameter in OAuth 1.0. b. On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofe...@nsn.com> wrote: > Dick pointed me to the Facebook API on how scope is used. > The main page is here: > http://developers.facebook.com/docs/authentication/ > > It describes the basic functionality and also lists an example: > > " > https://graph.facebook.com/oauth/authorize? > client_id=...& > redirect_uri=http://www.example.com/callback&; > scope=user_photos,user_videos,publish_stream > " > > The values of the scope parameter are then explained here: > http://developers.facebook.com/docs/authentication/permissions > > Example: user_photos ... Provides access to the photos the user has uploaded > > I think it provides a good example that the scope values are not opaque. > Opaque (in this context) means that only the entity creating it needs to > understand it and nobody else. Here the client needs to understand and set > them. > > However, one could argue that the scope values are already bound to the > specific entity the client requests to obtain the assertion from. In this > specific case it would be "https://graph.facebook.com";. > > To respond to the statement Dick made about having standardized values later > there would still be the need to decide about the structure of the values > now. One possibility is to just add a prefix for standardized values that are > not allowed to be used in other cases, such as "std:". > > Ciao > Hannes > > >> -----Original Message----- >> From: ext William Mills [mailto:wmi...@yahoo-inc.com] >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >> Rosenstock; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> I'm in favor of having a spaces separated list of tokens. >> The only case I can think of where the client needs to handle >> the scope as anything other than opaque is when it is >> accessing multiple services. To reduce the numebr of login >> events the client will have to poll all the endpoints it >> wants to access and get all the scopes advertized by them and >> submit them all, and once it has them it needs to submit all >> of them in it's auth request, so we need something that's >> easy for the client to put together. >> >> >> -bill >> >> > -----Original Message----- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >> > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> > Sent: Thursday, June 24, 2010 3:58 AM >> > To: ext Lukas Rosenstock; Dick Hardt >> > Cc: OAuth WG >> > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> > >> > The question is whether one would ever want to have a >> > standardized semantic for the scope parameter. >> > If the answer to that question is "no" then it does not >> > matter what the format is. It can well be a list of >> > space-delimited strings (as it is currently defined). >> > >> > An evironment specific semantic works well in cases where >> > entity X sets the value and later it receives the value >> > again. Only entity X needs to understand what it means. >> > >> > In some environments the use case is slightly different, >> > namely entity X and entity Y are from the same organization >> > and agree on the semantic. Usage of OAuth within an >> > enterprise might be such a case. >> > >> > Now, the usage of the scope parameter is, however, a bit >> > different in the spec. Section 4, for example, describes how >> > a client obtains an access token. How does the client know >> > what scope parameters to set and what the semantic is? >> > >> > Ciao >> > Hannes >> > >> > > -----Original Message----- >> > > From: ext Lukas Rosenstock [mailto:l...@lukasrosenstock.net] >> > > Sent: Thursday, June 24, 2010 10:49 AM >> > > To: Dick Hardt >> > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> > > >> > > Wasn't there some concensus that URIs would be good for >> scope? They >> > > have "in-built namespacing" ... >> > > >> > > Lukas >> > > >> > > 2010/6/23 Dick Hardt <dick.ha...@gmail.com>: >> > > > >> > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >> > > FI/Espoo) wrote: >> > > > >> > > >> " >> > > >> scope >> > > >> OPTIONAL. The scope of the access request >> > > expressed as a list >> > > >> of space-delimited strings. The value of the >> > > "scope" parameter >> > > >> is defined by the authorization server. If the >> > > value contains >> > > >> multiple space-delimited strings, their order does >> > > not matter, >> > > >> and each string adds an additional access range to the >> > > >> requested scope. >> > > >> " >> > > >> >> > > >> Do folks think it would be useful to have standardized values? >> > > > >> > > > Not at this time. The semantics of scope are all over the >> > > place. If standardized, people will feel they need to pick >> > one that is >> > > close to what they want, but is not exactly what they mean. >> > I think it >> > > is better for the AS to define what they mean by a scope >> > and give it a >> > > name that makes sense in that context. >> > > > >> > > >> >> > > >> If the answer is "yes", then it would be useful to >> > > differentiate the >> > > >> standardized values from those values that are purely >> > > defined locally by >> > > >> the authorization server. >> > > >> > _______________________________________________ >> > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
