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

Dick Hardt <dick.hardt@gmail.com> Thu, 30 September 2010 19:07 UTC

Return-Path: <dick.hardt@gmail.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 1BC793A6E4E for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 12:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 mSc3COxV8w11 for <oauth@core3.amsl.com>; Thu, 30 Sep 2010 12:07:35 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 0505B3A6D84 for <oauth@ietf.org>; Thu, 30 Sep 2010 12:07:34 -0700 (PDT)
Received: by pxi6 with SMTP id 6so782823pxi.31 for <oauth@ietf.org>; Thu, 30 Sep 2010 12:08:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=UyTyCFGBe+pzfFBS5kUhavsCBbU63BendZon4Wi3aEY=; b=EvM50CC1LunBy9e2K+pndTe6lntKuPzseF3qH61LKUn3/7HqSrobYO//AeE7FJDOj2 IyaWBjWoBU22xu0aYlNVO+gaBKJ2uqLr9JesfIwVWDL70lZPwYv8YmfL3nQssnsD6Mv0 ph6BPeHlEWIQUdkfpIO7RRyVD/8isOHM8RKdE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=xrktoK601T3V/e0t6myntsw5FmUoi1VNIeTzBkz5z7jZRXbj2pGpqnqPXRZvKWiwTV 5hnGkAkFv6jCMofKu5WqXTHs+GoYLX17VeKek8z/SmCjHoXCqwp+w5FcoxJCrfiG5VDD pFAIWUt/YCJc4ZIX1Xr8w6Dblz+z2hjxOYJS8=
Received: by 10.142.185.9 with SMTP id i9mr1327408wff.220.1285873701315; Thu, 30 Sep 2010 12:08:21 -0700 (PDT)
Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id t38sm192335wfc.21.2010.09.30.12.08.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 12:08:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D460DBD42@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 30 Sep 2010 12:08:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D736243-775D-47F4-95A2-F6BBE70481A3@gmail.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343D460DB5BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimDa0aZFgxuOczV9GJEF2EXOV4DSr6BK7mKAoqA@mail.gmail.com> <410FEF9C-CE06-4B08-A053-3D87C454D759@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343D460DBD42@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1081)
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 19:07:36 -0000

On 2010-09-30, at 11:33 AM, Eran Hammer-Lahav wrote:

>> -----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!

No, that is not what I was asking for. You are breaking it on "using a token". Your proposal does not create an independent signing spec. As stated, I don't have a concern with signatures being part of OAuth,

> 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.

If the WG is happy spending time on yet another experiment on moving around the content, please proceed.

You have not addressed my core point which is that the WG needs to come to agreement on which use cases are in scope, which I think is the underlying issue here. I think breaking the spec into 3 parts is just moving around deck chairs.

-- Dick