Re: [OAUTH-WG] 'Scope' parameter proposal

Luke Shepard <lshepard@facebook.com> Mon, 19 April 2010 17:27 UTC

Return-Path: <lshepard@facebook.com>
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 EA6C93A68C4 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 10:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1]
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 qg6cVa7i37gK for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 10:27:12 -0700 (PDT)
Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 2FFF53A69F8 for <oauth@ietf.org>; Mon, 19 Apr 2010 10:21:38 -0700 (PDT)
Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o3JHL6ve022961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Apr 2010 10:21:06 -0700
Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.689.0; Mon, 19 Apr 2010 10:21:23 -0700
Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Mon, 19 Apr 2010 10:21:23 -0700
From: Luke Shepard <lshepard@facebook.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, OAuth WG <oauth@ietf.org>
Date: Mon, 19 Apr 2010 10:21:21 -0700
Thread-Topic: 'Scope' parameter proposal
Thread-Index: Acrf3OTsH3nwWGe+ikabEbV7IE0sxQABSTMA
Message-ID: <2513A610118CC14C8E622C376C8DEC93D54D66DE26@SC-MBXC1.TheFacebook.com>
References: <C7F1D1FC.32809%eran@hueniverse.com>
In-Reply-To: <C7F1D1FC.32809%eran@hueniverse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-19_13:2010-02-06, 2010-04-19, 2010-04-19 signatures=0
Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
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 17:27:14 -0000

This seems pretty elegant to me. I like that in the general case, the protected resource can give an error saying the scope required.

As a specific example of how Facebook could use this, we have an extended permission for an app to publish to a user's stream. If an app tries to publish to the stream today, and they don't have the permission, we give an error that says "You need the publish_stream permission." With this extension, we could also add a header like:

WWW-Authenticate: Token realm="http://www.facebook.com", scope="publish_stream"

Then client libraries could craft an OAuth authorize URL for that scope, without having to refer to documentation.

One issue is how this would work with more complicated scenarios. There are resources that require multiple scopes, or even one of a few possible scopes (i.e., either "publish_stream" or "add_photo" to post a photo story). What are the semantics of the response header listing multiple scopes - are they all required, or just some?
 
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, April 19, 2010 9:25 AM
To: OAuth WG
Subject: [OAUTH-WG] 'Scope' parameter proposal

Proposal:

'scope' is defined as a comma-separated list of resource URIs or resource
groups (e.g. contacts, photos). The server can provide a list of values for
the client to use in its documentation, or the client can use the URIs or
scope identifier of the protected resources it is trying to access (before
or after getting a 401 response).

For example:

1. Client requests resource

    GET /resource HTTP/1.1
    Host: example.com

2. Server requires authentication

    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Token realm='Example', scope='x2'

3. Client requests an access token by including scope=x2 in the request

Alternatively, the client can ask for an access token with
scope=http://example.com/resource.

If the client needs access to two resource with different scopes, it
requests an access token for scope=x2,x1.

That's it!

It allows the client to figure out what value to put in the scope parameter
and how to encode multiple scopes without any server-specific documentation.
Servers that wish to rely exclusively on paperwork can just omit the scope
parameter from the WWW-Authenticate header.

We can pick a different separator (space, semicolon, etc.) or different
parameter name (resource(s)).

EHL


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth