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

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

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