Glad to see people agreeing with me. I don't think Hannes was disagreeing with me though. :)
Per my response to Hannes, I think there is value in a small restriction on scope strings so that we have a reserved format for the future. -- Dick On 2010-06-25, at 7:52 AM, Blaine Cook wrote: > 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
