Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues

Eran Hammer-Lahav <eran@hueniverse.com> Thu, 30 September 2010 18:33 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 783633A6E6A for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 11:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 aiYrSogqILqC for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 11:33:09 -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 9D2EE3A6E71 for <oauth@ietf.org>; Thu, 30 Sep 2010 11:33:06 -0700 (PDT)
Received: (qmail 11303 invoked from network); 30 Sep 2010 18:33:52 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Sep 2010 18:33:52 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 30 Sep 2010 11:33:44 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dick Hardt <dick.hardt@gmail.com>
Date: Thu, 30 Sep 2010 11:33:35 -0700
Thread-Topic: [OAUTH-WG] Looking for a compromise on signatures and other open issues
Thread-Index: ActgridnvzidNMejScae4OdS8JhIkwAFaUHg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343D460DBD42@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimDa0aZFgxuOczV9GJEF2EXOV4DSr6BK7mKAoqA@mail.gmail.com> <410FEF9C-CE06-4B08-A053-3D87C454D759@gmail.com>
In-Reply-To: <410FEF9C-CE06-4B08-A053-3D87C454D759@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)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Looking for a compromise on signatures and other open issues
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, 30 Sep 2010 18:33:10 -0000

> -----Original Message-----
> From: Dick Hardt [mailto:dick.hardt@gmail.com]
> Sent: Thursday, September 30, 2010 7:45 AM

> The suggested change does not address the issue that myself and others had
> raised with having signatures be in the core. The suggestion was that having
> signatures be a different spec made them reusable by other groups and
> enabled a more comprehensive signature specification. Having them in core
> made them OAuth specific.

Of course it does! It addresses it by keeping signature proposals as separate documents. This is exactly what you have been asking for! Now it is up to those working on each signature proposal to decided how generic they want to keep it.
 
> I think there was consensus with those that had seen the advantage of a
> different signature spec that including the OAuth 1.0A signature mechanism
> in core and having a clear extension mechanism was a satisfactory direction.
> This enables alternative algorithms to be specified

There was no consensus! Mike Jones and Marius Scurtescu outright objected, Anthony Nadalin was not supportive, you and Lukas Rosenstock raised concerns, John Panzer suggested he might be ok with it, and Mark McGloin said it is worth trying. That's it.

On the other hand, the proposal to break the specification has an overwhelming support: 13 people support it unconditionally, 2 raised concerns but are happy to give it a try, and 1 didn't see the point (but did not object). You are the only one with an actual objection (so far), and one which is pretty easy to test, and much faster than anything else suggested.

Breaking the specification will take a few days and will let us judge these assertions in practice. I suggest we move forward with this proposal and revisit your objection later when we have actual documents to discuss. If the result will prove to be unreadable, we can always go revisit, and the IETF process will give you plenty of opportunities to voice your concerns.

EHL

[1] http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/