+1 to the "Device" idea. About a year ago I brought up the idea of having an instance identifier as an OAuth extension, but that never got traction and I dropped the thread.
-- justin On Mon, 2010-04-19 at 09:03 -0400, Torsten Lodderstedt wrote: > +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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
