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

[Joseph Smarr <[e-mail]>]

+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
>