IETF Logo Mail Archive

Re: [OAUTH-WG] Issue: Scope parameter

Eran Hammer-Lahav <eran@hueniverse.com> Fri, 16 April 2010 15:51 UTC

Return-Path: <eran@hueniverse.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 6A81F28C0F9 for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 08:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 uq2vJ0S+rHZC for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 08:51:25 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EA8E43A67C2 for <oauth@ietf.org>; Fri, 16 Apr 2010 08:51:24 -0700 (PDT)
Received: (qmail 22729 invoked from network); 16 Apr 2010 15:51:18 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Apr 2010 15:51:16 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Apr 2010 08:51:16 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Justin Smith <justinsm@microsoft.com>, OAuth WG <oauth@ietf.org>
Date: Fri, 16 Apr 2010 08:51:12 -0700
Thread-Topic: [OAUTH-WG] Issue: Scope parameter
Thread-Index: AQHK3NEWvq+1OOTFrkS1RWT2flQ40pIkXsgAgAADXwCAAAODAP//ySWwgAAfiRCAACcXIIAAAxeggAAHW5CAAAKQEIAAsiuwgAALCA0=
Message-ID: <C7EDD580.32401%eran@hueniverse.com>
In-Reply-To: <191F411E00E19F4E943ECDB6D65C60851691FCA9@TK5EX14MBXC115.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7EDD58032401eranhueniversecom_"
MIME-Version: 1.0
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: Fri, 16 Apr 2010 15:51:30 -0000

You are make my point. A scope parameter is useless without another vendor-specific spec in which case the vendor spec can define its own scope parameter. The argument of library support doesn't hold because libraries must pass any extension parameter anyway.

If people still want a scope parameter, they must define it in a way that it doesn't require vendor-specific knowledge. I am not sure this is possible or that useful.

EHL


On 4/16/10 8:25 AM, "Justin Smith" <justinsm@microsoft.com> wrote:

It isn't clear to me how those options are better for interop than a scope parameter in the token request.

Also, the proposal forces the protected resource to know the context of the request and respond with the appropriate URI. This simply won't work in many situations. For example, let's say foo.com and bar.com may be bundled and available individualy. A client might need one access token that grants permission to both resources, another client might only get an access token that grants permission to one resource. With the proposal below, foo.com can't respond with the correct value in the 401 (should the URI reference the individual service or the bundle).



From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
Sent: Thursday, April 15, 2010 9:44 PM
To: Justin Smith; OAuth WG
Subject: RE: [OAUTH-WG] Issue: Scope parameter

> So, let's say there is an Authorization Server available at http://as.com and it protects the http://foo.com and http://bar.com resources.

> A client requests  http://foo.com. The foo.com server responds with a WWW-Auth that contains the http://as.com URI. The client then sends an access token request to http://as.com. Is that right?

> If so, then how does http://as.com know that the intended resource is http://foo.com?


Foo.com should point the client at, say, http://as.com/foo/ or http://foo.as.com/ or http://as.com/?scope=foo or http://as.com/?encrypted_resource_id=273648264287642 or whatever it has agreed to with its AS.
The WWW-Auth response from foo.com should not be just http://as.com.
Foo is much better placed to know it shares as.com with Bar than a client is.

--
James Manger

v2.23.0 | Report a Bug | By Email