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

[Eran Hammer-Lahav <[e-mail]>]

That's coming in -09.

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> 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: [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