I'm ok with that if we provide some guidance in the spec to implementors that recommends the use of URIs for scopes they expect to be standardized.
On 2010-06-25, at 11:14 AM, Eran Hammer-Lahav wrote: > I like the idea of an extensibility mechanism for standard scopes, but I am > not sure I like the idea of a prefix or reserved characters. Using URIs as > scope values was a requirement (and something that is currently deployed by > Google). We defined space-delimited to make simple strings and URIs possible > as values. > > My question is, why isn't URIs enough for standard scopes? Define simple > strings as server-specific and allow URIs to be used in standards (which will > solve potential name collisions). It might make standard scopes a bit less > cool but that's not a technical argument. I also think scopes are likely to > be extended a lot more than other extension types and would like to keep the > process as light as possible (i.e. no registration at all). > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Dick Hardt >> Sent: Friday, June 25, 2010 8:50 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> To clarify, the goal is to reserve a namespace for future use so that near >> term >> implementations won't collide? >> >> I expect the standardization of scope values to not be in OAuth, but in >> standardized APIs that use OAuth, so a namespace mechanism that >> differentiates between a standardized scope and an implementation specific >> scope may be useful. >> >> From what I have gathered, implementors are leaning towards simple strings >> rather than URIs to declare scope. Perhaps reserving the ":" character from >> being in a scope string unless the scope prefix has been registered with >> IANA? >> >> -- Dick >> On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) 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
