+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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
