Re: [OAUTH-WG] 'Scope' parameter proposal

[Eve Maler <[e-mail]>]

Folks-- I'm desperately trying to catch up on the list traffic after an enforced couple of weeks away (pity me :-).  This seems to be the freshest scope thread; let me know if I'm missing a newer one. I just wanted to remind people about the previous JSON-flavored proposal from the UMA group for standardizing expressions of scope, e.g.:

[{"method": "GET", "uri": "http://example.com/foo"},
{"method": "POST", "uri": "http://example.com/*"}]
We were interested in this approach because many of UMA's use cases deal with protecting access to web resources for simple data-sharing, e.g. GET access to all the photos in a directory, or to a single web resource that represents some identified chunk of the user's identity data. But it could also be pretty useful for any API that achieves at least level 1 in the "REST maturity model" (http://www.infoq.com/news/2010/03/RESTLevels -- obviously the particular semantics beyond the method/uri pair still needs to be documented, but this would encourage such documentation and more-standard APIs).

URL-encoding this obviously gets a bit ugly, but the basic form is otherwise readily processable. There was a bit of interest expressed on the OAuth Google group when I brought this up about a month ago, and I previously explored some of the implications in a discussion with Dick in the "Recent UMA work that may inform this group's deliberations" thread on this list about six weeks ago. (I couldn't find archives that went back this far in order to link to the thread. What am I missing?)

It seems like this proposal "goes there" in terms of getting as expressive as Eran fears, though the addition of the wildcard takes away a good deal of the pain depending on the particular interface at the endpoint(s). Is there any wider interest in "going there"?

	Eve

On 20 Apr 2010, at 9:18 AM, Joseph Smarr wrote:

> +1 to nailing down how to pass scopes, as Eran suggests (I think space-delimited URLs is best, but that's a detail). Having implemented OAuth with probably a dozen different providers (while at Plaxo), scopes were always one of those things that just didn't fit cleanly into my libraries and abstractions. Specifying a standard place for scope to go is one step, but the choice of scopes were all still hardcoded in a per-domain config file, which is a pain. 
> 
> Worse, it makes it very hard to handle standard protocols like Portable Contacts -- I want to be able to write a "contact importer from any Portable Contacts provider", where the user types in the domain of their provider, and the rest is automagic. Achieving this goal probably requires some amount of discovery, and some ability to use "unregistered/anonymous mode", but it also requires knowing which scopes to pass in. And the first two are pretty easy to solve (include a PoCo entry in your site's /.well-known/host-meta and allow anonymous/anonymous as consumer key/secret), so the scopes thing is really the gating factor here.
> 
> Also +1 to Eran's meta-point that the job of a spec like this should be to reach as far as possible towards specified behavior for interop. Just like we defined a large number of contact fields in PoCo, the point was not "everyone has to support all of these", but rather "if multiple parties want to support any of these, now they have an agreed-upon way to do so". And with scope, I hope by now it's well established that scopes are going to be common and the status quo badly under-specifies how to query for them and use them.
> 
> Thanks, js
> 
> On Tue, Apr 20, 2010 at 8:42 AM, Eran Hammer-Lahav <[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: Dick Hardt [mailto:[e-mail]]
> > Sent: Monday, April 19, 2010 8:07 PM
> > To: Eran Hammer-Lahav
> > Cc: OAuth WG
> > Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
> >
> >
> > On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote:
> > > 2. Server requires authentication
> > >
> > >    HTTP/1.1 401 Unauthorized
> > >    WWW-Authenticate: Token realm='Example', scope='x2'
> >
> > Can more than one scope be returned? Is it a comma delimited list?
> 
> One scope parameter with one or more comma-delimited values (we can change this to space delimited if people would like to use URIs for scope identifiers).
> 
> > Imagine we have a resource that can have READ or  WRITE access granted.
> >
> > An unauthenticated GET on the resource could return the scope URI needed
> > for READ, an unauthenticated PUT on the resource could return the scope
> > URI for WRITE. What if you want to both do READs and WRITEs? There may
> > be another scope that is READ/WRITE. READ and WRITE are pretty common
> > capabilities, but one can imagine much more complex capabilities at
> > resources.
> 
> A failed GET will return scope=read and a failed PUT will return scope=write. The server can issue an access token with:
> 
> scope=read
> scope=write
> scope=read,write
> 
> The last can be used for both. In other words, there should not be a read_write scope, instead, the token should have two scopes.
> 
> > The exact semantics to the resource are likely going to very contextual.
> 
> Yes, and this can get very complicated if people want an extremely granular way of doing permissions. For example, if you want to issue a token that can read contacts and write email, you will need to define a bigger set: email_read, email_write, contacts_read, contacts_write. On the other hand, if a write access is for all authorized resources, you need: email, contacts, read, write.
> 
> > Given that, returning a single scope value if that is all that makes sense to the
> > resource will likely address many use cases.
> 
> This is true when looking at a single resource.
> 
> EHL
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler
[e-mail]
http://www.xmlgrrl.com/blog