Re: [OAUTH-WG] Issue: Scope parameter

+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 <lshepard@facebook.com>:
> 
> > David Recordon <recordond@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