That's coming in -09. EHL
> -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Friday, June 25, 2010 11:19 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > 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
