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

Eric Sachs <esachs@google.com> Fri, 24 September 2010 00:29 UTC

Return-Path: <esachs@google.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 709E03A682C for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 17:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 wVncCB4JiJnY for <oauth@core3.amsl.com>; Thu, 23 Sep 2010 17:29:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 889983A6804 for <oauth@ietf.org>; Thu, 23 Sep 2010 17:29:37 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o8O0U7Zo016683 for <oauth@ietf.org>; Thu, 23 Sep 2010 17:30:07 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285288207; bh=kbvNX8meX/l8tLqrV7SIWmGV1L4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=u4eNKfYWQMuaQz9SPrAVQtnz4U+oLIwYHOC2tkBB5OvYDCoXx3SGNqcw9Kfh7zCIh bVn5gVdxLTvJ/rMGiwy8w==
Received: from gyd5 (gyd5.prod.google.com [10.243.49.197]) by hpaq3.eem.corp.google.com with ESMTP id o8O0U5jb028560 for <oauth@ietf.org>; Thu, 23 Sep 2010 17:30:06 -0700
Received: by gyd5 with SMTP id 5so901616gyd.37 for <oauth@ietf.org>; Thu, 23 Sep 2010 17:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Ld2KJn/bgwP2CMqlway+w1sqDRJcm99ED2MfWnJ3P9M=; b=GIXGFXzniDM6yJpdx+oGOW0USf0i259Nr56kjE0HGQEuHY0wKMlTqd/o178qW6d5Iz gD7a0T58eSfjkEiVmwZw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=RdStEuTiKwwEpU51DtcPhcATpQa+G04XOpauz0EEbzgo4rpJ7kky3hNbmzeLVwf5He FsJ5quldqo0cYFLETIyg==
MIME-Version: 1.0
Received: by 10.150.200.6 with SMTP id x6mr3735135ybf.349.1285288205279; Thu, 23 Sep 2010 17:30:05 -0700 (PDT)
Received: by 10.150.199.16 with HTTP; Thu, 23 Sep 2010 17:30:05 -0700 (PDT)
Date: Thu, 23 Sep 2010 17:30:05 -0700
Message-ID: <AANLkTinjjg1Fj5bVmtnngYqg1fFOLzUbrqSHZ9P-oHWq@mail.gmail.com>
From: Eric Sachs <esachs@google.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000e0cd34832e8e3ab0490f67a9f"
X-System-Of-Record: true
Subject: [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:29:43 -0000

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.