On Tue, Apr 6, 2010 at 3:12 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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?
You are probably right, an opaque scope does not help interop. I think the reason the scope parameter was added to wrap is that in practice with OAuth most implementations ended up needing such a parameter. Having a standard one prevents everyone from (re)inventing a custom parameter. Beyond that, I don't see any benefits. > 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? Set of resources and access rights probably go together in a scope. Not so sure about duration, until now duration was considered unlimited, Authz Servers probably allow users to revoke access at any time (this would revoke the corresponding refresh token and any auto-approvals). > 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? I think the vague definition from the wrap spec was good enough: "The Authorization Server MAY define authorization scope values for the Client to include" Marius > > 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
