Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

Dick Hardt <dick.hardt@gmail.com> Fri, 24 September 2010 01:29 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 BFFD33A6900 for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 18:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 grk3JzR06qjg for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 18:29:50 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E1B673A6804 for <oauth@ietf.org>; Thu, 23 Sep 2010 18:29:49 -0700 (PDT)
Received: by pwi1 with SMTP id 1so638398pwi.31 for <oauth@ietf.org>; Thu, 23 Sep 2010 18:30:20 -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:message-id:references:to :x-mailer; bh=8L/SZuZ4i0SXvX7BUbvTq+lSBlrtkJA/SXgnksSnGus=; b=OfkequoXHh59+VUStirL9rQFUCFI6wGAfeGhUFajL+JK54VXXUnuI6ZZ6eM46jw5GM Vz9pTG69DZdOecH8WGH2wsG5CpM9nxy/eW0vu+YFElYpzQ21OCJSKVC0iCyxXZKqntRN Vk6OMmTybzI6tLAvgQD0/wWRGkc7L4GMtYVQQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=buWk/F0r90Fabe7OTjCoMRk21vt8kgxro4Zvm5v9HhvstwXxDeI7lYMWcOD2tgXTe7 tHxbs4L2yQa3jx3xjpujW/QAyJO6ZH9iPU+yPuaX2igtJXhC5H4Q7FSb2L7sM42eM7kJ kmNTiuWfWjikDaRXGbl8t00Wi8D3XA5ulk86c=
Received: by 10.114.121.18 with SMTP id t18mr2649930wac.136.1285291820396; Thu, 23 Sep 2010 18:30:20 -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 d38sm2506430wam.20.2010.09.23.18.30.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Sep 2010 18:30:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-71--105545053"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <C8C148D3.3AC59%eran@hueniverse.com>
Date: Thu, 23 Sep 2010 18:30:16 -0700
Message-Id: <1CFAB616-FB50-4CC3-938B-D557FD9992ED@gmail.com>
References: <C8C148D3.3AC59%eran@hueniverse.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
X-Mailer: Apple Mail (2.1081)
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
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, 24 Sep 2010 01:29:51 -0000

I agree with your point that consensus is based on individual voices.

I agree with Eric's points that signatures are a generic security mechanism and that signatures should be in a separate spec. 

-- Dick


On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:

> It is pretty clear from the recent public response that a core specification without signatures is going to be viewed as weak and insecure. This has been my position for over a year, and if it wasn’t clear, I am going to continue expressing it.
> 
> We have enough interest to get a basic signature support in the core specification, one that is not driven by enterprise use cases, complex identity solutions, or large distributed systems. Given the recent Twitter migration to OAuth 1.0a proved that with a big enough carrot (or stick, depending on your view), developers figure it out. I believe that an OAuth 1.0a style signature can be easily developed and added to the core specification as an optional feature.
> 
> This is not new. This was agreed upon at the Anaheim meeting. I took the signature language out of the draft in order to focus the discussion on the other components. Now that –10 is pretty solid (normative language-wise), it is time to bring it back in.
> 
> Draft –11 will include a signature proposal, even if that means a short delay.
> 
> The arguments about delaying the core spec are meritless, given that a growing number of companies are releasing OAuth 2.0 APIs using the latest stable draft. We can easily do a WGLC for the current stable components, and add signatures without changing those. This working group does not make technical and architectural decisions based on the timeline needs of any company. We do what is best for the web and we take as much time as necessary.
> 
> As an aside, while companies can certainly express their corporate position on matters, this is a working group of individuals, and consensus is based solely on individual voices.
> 
> EHL
> 
> 
> 
> 
> 
> 
> On 9/23/10 5:30 PM, "Eric Sachs" <esachs@google.com> wrote:
> 
> Google wanted to re-state our long standing opinions on HTTP signature mechanisms in the OAuth2 spec.  The short version is that standards for signing parts of an HTTP request have value in use-cases other than OAuth2, and thus they should be defined outside the spec, and just referenced from the spec similar to how we reference other Internet security building blocks like SSL.  Those signature standards are likely to in turn reference optional mechanisms for key rotation and discovery, as well as reference different crypto schemes like HMAC or RSA.
> 
> There are already people in the identity community working on specs that are related to OAuth2, but which have value in other use-cases.  For example, there are people working on defining standards around token formats, signing blobs of different types (such as a token and/or HTTP request), key discovery/rotation, and consumer-key namespaces across vendors.  Dirk Balfanz from Google recently sent out updated drafts of some of those specs, and they also leverage specs that John Panzer from Google has worked on for Magic Signatures, as well as input from people in the community who are not at Google.
> 
> However even though Google is working on those specs, we still believe it is a mistake to delay the OAuth2 core spec standard to wait on broad agreement for a "signature proposal," just as it would be a mistake to delay the OAuth2 core spec to wait on the standards efforts around token formats, token signing, key discovery/rotation, consumer-key naming, etc.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth