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: [email protected] [mailto:[email protected]] 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:[email protected]] > >> 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: [email protected] [mailto:[email protected]] > >>> 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:[email protected]] > >>>> 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 <[email protected]>: > >>>>> > >>>>> 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
