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

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 19 April 2010 21:21 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 4DF793A6B32 for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 14:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 uuyEuOZjzFCO for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 14:21:32 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B25193A6B30 for <oauth@ietf.org>; Mon, 19 Apr 2010 14:21:06 -0700 (PDT)
Received: (qmail 13712 invoked from network); 19 Apr 2010 21:20:57 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Apr 2010 21:20:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 19 Apr 2010 14:20:57 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 19 Apr 2010 14:20:56 -0700
Thread-Topic: [OAUTH-WG] 'Scope' parameter proposal
Thread-Index: AcrgAeXKiZIKTVBoQleEBqLZ4pZd7wAAbIBQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F2BC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <C7F1D1FC.32809%eran@hueniverse.com> <j2q74caaad21004191103l488ae334j78d5546479f66cb8@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F17F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <x2q74caaad21004191349p9969878aob14135d7069dd593@mail.gmail.com>
In-Reply-To: <x2q74caaad21004191349p9969878aob14135d7069dd593@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: Mon, 19 Apr 2010 21:21:35 -0000

> -----Original Message-----
> From: Marius Scurtescu [mailto:mscurtescu@google.com]
> Sent: Monday, April 19, 2010 1:50 PM

> How does defining the scope structure help interop?

Clients can use scopes the same way across provides and don't need to read paperwork to figure out how to use the parameter. It allows smooth and seamless interaction with an unfamiliar server using an open API format.
 
> There was a good argument why not define it. Getting everyone to agree on
> one definition can be hard, and you cannot be sure everyone was consulted.
> There are lots of service providers out there that use scopes today. Are we
> sure that a space separated list of URIs will work for all of them?

Everything is hard to agree on - welcome to the wonderful work of standards. The signatures discussion took months for example. But you can't make this argument without even trying. Let's spend a week discussing a proposal (or others if people want to submit more) and see where we end up. As for those not participating, well, that's their problem. Seriously, if you don't bother to show up and participate you have absolutely no say. Specs are created by those who show up.

> When you wanted to leave scopes out altogether, you wanted proof they
> are needed :-)

That wasn't my position. My position was that the parameter was underspecified and as such added no value. I tried repeatedly to discuss ideas on how to define it but you and others just shot me down every time arguing it must be vendor-specific.
 
> I did a proof of concept implementation, with client, server and protected
> resource support libraries, and the scope structure was never an issue.
> Actual client, server and resource code, does need to deal with scopes, but
> this is not the generic code that would go into a library.

Did your library handle unknown parameters, passing them through the call stack?

> I do agree that it would be nice to have a defined structure for scopes, I just
> don't think it is that important and that it is hard to get right.

I disagree on both. It is important and not so hard to get right, just like any other feature we decide to include. How would you know if we don't even try?

This exact argument was made 3 years ago. Dick Hardt asked for a scope parameter. As editor I added a generic scope parameter to the spec called oauth_token_attributes. However the group consensus was that it was underspecified and lacked any implementation experience. We drop it and decided to revisit in an extension. That never happened. Instead, each vendor made up their own parameter. We are back where we started now, with the same arguments. I think 3 years is plenty experience to get this done right.

EHL