Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?

[Dick Hardt <[e-mail]>]

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