The interop value of the current proposal is simple: - defines how multiple scopes are to be expressed (order doesn't matter, space delimited) - provides an easy way to express the required scope when rejected a protected resource request - allows clients the ability to combine scopes (known and discovered) without additional server-specific logic
I think this is enough value to define an internal structure to the scope string beyond just a blob. The current proposal doesn't prevent the YQL example you provided, just that it needs to be encoded to replace the spaces with something else (since space delimited order does not matter). We want to keep scope underspecified enough to allow the level of customization currently expressed by the different vendors represented here. But we also want to make sure that defining interop scopes is well understood and simple as we already have a few use cases for it (e.g. OpenID Connect, Portable Contacts). EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Blaine Cook > Sent: Friday, June 25, 2010 7:53 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
