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

[Blaine Cook <[e-mail]>]

I agree with Dick that the scope should remain out of scope for OAuth.
;-) Having a shared parameter here gives the illusion of
interoperability, but because there's no common understanding of
permissible scopes, there's no way to guarantee that any given
client-server pair could expect to produce predictable outcomes.

Furthermore, limiting the format of the scope prematurely means that
we give up on a whole set of possibilities before we've even had a
chance to see what those possibilities are. For example, YQL might
want to allow a scope to be defined like "SELECT * FROM flickr" or
something similar. Maybe scope is implicit in assertions, or even
explicit. Scope might be tied to the degree to which the requesting
and/or granting parties are trusted by the service provider.

If there were a compelling story about how scope is supposed to
realistically achieve greater interoperability, it might be worthwhile
for us to consider it. In the meantime, though, I think it just
represents the same featuritis drive that got us an under-specified
(and more harmful than helpful) version parameter in OAuth 1.0.

b.

On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo)
<[e-mail]> 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
>