Re: [OAUTH-WG] Scope - Coming to a Consensus

[Torsten Lodderstedt <[e-mail]>]

+1 on option 3.

Am 30.04.2010 17:43, schrieb Eran Hammer-Lahav:
> 3. Space-Delimited Scope Parameter Value
>
> Define a 'scope' parameter with value of space-delimited strings (which can include any character that is not a space - the entire parameter value is encoded per the transport rules regardless). Space allows using URIs or simple strings as values.
>
> Pros:
>
> - A separator-delimited list of values is the common format for scope parameters in existing implementations and represents actual deployment experience.
> - Most vendors define a set of opaque strings used for requesting scope. This enables libraries to concatenate these in a standard way.
> - Enables simple extensions in the future for discovering which scope is required by each resource.
>
> Cons:
>
> - Defining a format without a discovery method for the values needs doesn't offer much more than the other options.
>    

In my opinion, automatic discovery on scope values is as valuable or not 
valuable as automatic discovery for a service API. I would like to echo 
one of my postings:

A scope defines the set of permissions a client asks for and that 
becomes associated with tokens. I don't see the need (and a way) for 
automatic scope discovery. In my opinion, scopes are part of the API 
documentation of a particular resource server. So if someone implements 
a client, it needs to consider the different scopes this client needs 
the end users authorization for. If the resource server implements a 
OAuth2-based standard API (e.g. for contact management or e-Mail), a 
client might be interoperable (in terms of scopes) among the resource 
servers implementing this standard.

> - Doesn't go far enough to actually achieve interoperability.
> - Adds complexity for little value.
>    

I think it adds a lot of value. It introduces the concept of client 
permissions to OAuth, which allows to restrict client access to services 
at a fine-grained level. At Deutsche Telekom, we have some use cases 
requiring such a feature and would be happy to see it supported by the 
standard.

regards,
Torsten.





>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>