+1 to #1 (as starting point)
In my opinion, the WG should try to work towards #2. Would it be
possible to first collect what kind of "scope" implementations use
today and what ideas exists?
Based on our experiences with implementing OAuth 1.0a at Deutsche
Telekom, I see the following aspects:
- resource: specification of the protected resource to be accessed. An
example could be: "http://www.example.de/photos/"; or just "photos".
This is a more conceptual view that can be understood by users
(relevant for user consent), whereas the service id is a more
technical view.
- service id: identifier of a web service exposing certain functions
to access/manipulate resources on a particular channel using a
particular technology (Rest, SOAP, ...).
Examples could be: "photos-rest-proxy-iptv", "photos-soap-intf-mobile".
Different services may need different user data, thus content of
self-contained tokens typically varies between service id's.
- permissions: permissions on resources or services the client wants
to get authorized by the user (comma-separated list of opaque
strings). The range of permissions is defined by the resource/service
as part of its API design. This could be something like "upload",
"download", "sent", or "establish connection".
- duration: specification of the token duration the client asks for
- device: the device the OAuth clients resides on. This allows to have
different tokens for the same client (application) on different
devices and is intended to reduce the impact of token theft. The token
is bound to a particular device during user authz flow and usage of
the token is restricted to that device only (typically mobile/smart
phones, but also set top boxes, tv sets, gaming consoles).
regards,
Torsten.
Zitat von Luke Shepard <lshep...@facebook.com>:
David Recordon <record...@gmail.com> wrote:
Does anyone have an implementation example where comma separated
strings wouldn't work for the scope parameter?
Marius wrote:
Yes, Google currently is using a space separated list of URIs.
Why does the format matter?
I agree. Facebook uses comma-separate strings, Google uses
space-separated URLs- why is this a problem?
It seems we have three options:
1/ We leave the scope parameter as an Auth Server-specific, opaque parameter.
2/ We all agree on a format and spec for the scope parameter.
3/ We drop the scope parameter and make each server define their
own, non-standard scope param.
I think David proposed #2 as a way to address concerns on this list
that #1 would be a hindrance to interop. But I personally vote for
#1 now - we would add a spec later if it proves to be a problem.
_______________________________________________
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
