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...@hueniverse.com>
> wrote:
>
>
> > -----Original Message-----
> > From: Dick Hardt [mailto:dick.ha...@gmail.com]
> > 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
