I am still waiting for someone to show how a scope parameter with an opaque value helps interop, where every single example requires the client to know how to construct this opaque string. OAuth libraries will need to support extension parameters - that's a given. So how is this not an extension if you will have to document how to use it in your own API spec?
If I want to ask for both a set of resources (photos, contact), access rights (read, write), and a specific duration (3 days), should I put all this into the scope parameter? Put some in and some in another parameter? Help me write a definition that helps people understand exactly when and how they should use this parameter. How are you going to use it? EHL On 4/6/10 2:57 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: On Tue, Apr 6, 2010 at 2:42 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > The question is how your APIs are structure. Do you have APIs that require > multiple "scopes" in a single call? Things can get even more complicated. When the user grants access for the client, the approval page should list all the scopes the client is requesting. This is the set of scopes needed by the client for *all* the API calls. Each API will need a subset of this approved, larger set. With that in mind, it would be useful to be able to down-scope access tokens when using the refresh token, this way the client can send the smallest set of scopes with each API call. But again, for all the above, the client must have intimate knowledge of the APIs (aka protected resources) and what scopes are required, the OAuth 2.0 libraries used by the client can treat the scopes as opaque strings IMO. Marius > > EHL > > > On 4/6/10 8:29 AM, "Luke Shepard" <lshep...@facebook.com> wrote: > > For Facebook at least, we are currently planning to use scope as a > comma-separated list of permissions from this set: > http://wiki.developers.facebook.com/index.php/Extended_permissions > > For instance: > > oauth_scope=read_stream,email,photo_upload > > I'm not sure if that maps to realm exactly. > > On Apr 6, 2010, at 8:03 AM, Dick Hardt wrote: > >> >> On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote: >> >>> >>> >>> >>> On 4/2/10 3:27 PM, "Dick Hardt" <dick.ha...@gmail.com> wrote: >>> >>>> There are times when a resource may have different scope for different >>>> kinds >>>> of access. realm != scope >>> >>> No. Realm is a subset. It is what people define as the protected segment >>> name. >> >> Different Protected Resources could require the same scope, so I see realm >> and scope as being orthogonal. >> >>> For any other scope attribute we need to first define it. >> >> Why? Scope will often be application specific. >> >> _______________________________________________ >> 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
