Re: [OAUTH-WG] Issue: Scope parameter

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 19 April 2010 13:03 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7B23A69DA for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 06:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.346
X-Spam-Level:
X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSH7jmxq8WF6 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 06:03:48 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id 891433A6833 for <oauth@ietf.org>; Mon, 19 Apr 2010 06:03:48 -0700 (PDT)
Received: from [80.67.16.111] (helo=localhost) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1O3qdW-0001US-QA; Mon, 19 Apr 2010 15:03:38 +0200
Received: from ( [195.243.113.249]) by webmail.df.eu (Horde Framework) with HTTP; Mon, 19 Apr 2010 15:03:38 +0200
Message-ID: <20100419150338.19825npsatjgfesk@webmail.df.eu>
Date: Mon, 19 Apr 2010 15:03:38 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: Luke Shepard <lshepard@facebook.com>
References: <C7ECB1F7.32357%eran@hueniverse.com> <h2l987bab591004181812ve43197f9la55f59b753bd2959@mail.gmail.com> <o2wfd6741651004181838ob1dda59bpf7cb88d3b1892c1d@mail.gmail.com> <1676FB17-48B2-4125-991C-CE996C4DE66B@gmail.com> <g2sfd6741651004181904q2f242fcexf2f7892c9b512068@mail.gmail.com> <z2o74caaad21004182112he72e1a33i4397e2d5333a0c13@mail.gmail.com> <2513A610118CC14C8E622C376C8DEC93D54D66DDF6@SC-MBXC1.TheFacebook.com>
In-Reply-To: <2513A610118CC14C8E622C376C8DEC93D54D66DDF6@SC-MBXC1.TheFacebook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2)
X-Originating-IP: 195.243.113.249
X-Df-Sender: 141509
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: Scope parameter
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 13:03:50 -0000

+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
>