I don't agree: these values are still opaque to OAuth. They're not
opaque to the client and server, they're part of the API. But the client
-- and by "client" here I mean the whole client application, not just
the OAuth client -- needs to know what they're for. In the same fashion,
the client needs to know where to send the tokens to get user photos.
What's more important is that the functionality around the OAuth
transaction be transparent to any OAuth implementation or library. I
should be able to build a Facebook client on top of any compliant OAuth
library. Well, once Facebook is compliant of course. ;) But that client
should be able to call oauthReq.setScopes("user_photos", "user_videos",
"publish_stream") from a library and have it passed through the system
as expected.
-- Justin
On Fri, 2010-06-25 at 03:59 -0400, 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:wmi...@yahoo-inc.com]
> > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> > > 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:l...@lukasrosenstock.net]
> > > > 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 <dick.ha...@gmail.com>:
> > > > >
> > > > > 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
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
