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
