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

Anthony Nadalin <tonynad@microsoft.com> Fri, 24 September 2010 00:45 UTC

Return-Path: <tonynad@microsoft.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 B8D3C3A6804 for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 17:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.157
X-Spam-Level:
X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 LR-J+dQmyCce for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 17:45:16 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 7CBC43A688F for <oauth@ietf.org>; Thu, 23 Sep 2010 17:45:16 -0700 (PDT)
Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Sep 2010 17:45:45 -0700
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.200]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0218.012; Thu, 23 Sep 2010 17:45:46 -0700
From: Anthony Nadalin <tonynad@microsoft.com>
To: Eric Sachs <esachs@google.com>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Thread-Index: AQHLW3/ADVL0CKGC8EKUkUPu7YYsPpMgSz5w
Date: Fri, 24 Sep 2010 00:45:46 +0000
Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E70BEB0C@TK5EX14MBXC101.redmond.corp.microsoft.com>
References: <AANLkTinjjg1Fj5bVmtnngYqg1fFOLzUbrqSHZ9P-oHWq@mail.gmail.com>
In-Reply-To: <AANLkTinjjg1Fj5bVmtnngYqg1fFOLzUbrqSHZ9P-oHWq@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.123.12]
Content-Type: multipart/alternative; boundary="_000_1990A18DEA6E97429CFD1B4D2C5DA7E70BEB0CTK5EX14MBXC101red_"
MIME-Version: 1.0
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 00:45:17 -0000

Eric, Microsoft shares some of the same views, we would like to see the WG charter expanded to cover these additional items (so we have a home for these), we would like to see that proposed and agreed upon at the November meeting if at all possible.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eric Sachs
Sent: Thursday, September 23, 2010 5:30 PM
To: OAuth WG
Subject: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

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.