IETF Logo Mail Archive

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

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 22 April 2010 19:13 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 DD62028C205 for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 12:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599]
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 8JF6n2FiLDpc for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 12:13:17 -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 47D0028C2DF for <oauth@ietf.org>; Thu, 22 Apr 2010 11:54:39 -0700 (PDT)
Received: (qmail 8638 invoked from network); 22 Apr 2010 18:54:28 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Apr 2010 18:54:28 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 22 Apr 2010 11:54:21 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Eaton <beaton@google.com>, John Kemp <john@jkemp.net>
Date: Thu, 22 Apr 2010 11:54:10 -0700
Thread-Topic: [OAUTH-WG] 'Scope' parameter proposal
Thread-Index: AcriTFoA2VzeqCiSTwSsREEjmgbUgwAAGnZg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD17@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <C7F1D1FC.32809%eran@hueniverse.com> <0D5497F5-75A7-4A42-9A5E-9C2310162B18@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F30A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <g2mdaf5b9571004221036j5d6837f6z4d7959d69a3cbb2b@mail.gmail.com> <BB02FD4F-071E-4FF5-B3D0-F8D3FA22FEEE@jkemp.net> <z2gdaf5b9571004221147le5e5ab08laeaf24595dfc7f5e@mail.gmail.com>
In-Reply-To: <z2gdaf5b9571004221147le5e5ab08laeaf24595dfc7f5e@mail.gmail.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
Cc: OAuth WG <oauth@ietf.org>
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: Thu, 22 Apr 2010 19:13:24 -0000

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@google.com]
> Sent: Thursday, April 22, 2010 11:48 AM
 
> On Thu, Apr 22, 2010 at 11:39 AM, John Kemp <john@jkemp.net> wrote:
> > I agree that 'scope' is something that many SPs want. If they don't
> > want it roughly the same way though (something more than a "bucket of
> > opaque strings with a standard
> > name") I don't know if I understand the point to standardizing it.
> 
> Well, we've moved from "opaque string" to "bucket of opaque strings".

And that's where we should stop. That's as far as required given the way scope is widely used today.

> And from there, we could in theory move to "bucket of opaque strings that
> represent privileges, and well defined ways of dropping those privileges".

We only need to make sure not to prevent it. We should not specify something that is too limited to begin with. I don't think we have.
 
> This is hand-wavy, but the main reason I see to standardize a scope
> parameter is that it helps developers with a consistent mental model of how
> service providers work.  It also helps new service providers be consistent
> with the way previous APIs have been built.

If that is all you want to accomplish we can describe such a mechanism without naming a parameter. What you are describing is prose, not normative language.

EHL

v2.23.0 | Report a Bug | By Email