[OAUTH-WG] signatures, v2

Dirk Balfanz <balfanz@google.com> Fri, 16 July 2010 00:43 UTC

Return-Path: <balfanz@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 8695B3A6893 for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 17:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qhyXDrI2yaVv for <oauth@core3.amsl.com>; Thu, 15 Jul 2010 17:43:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 09F013A6860 for <oauth@ietf.org>; Thu, 15 Jul 2010 17:43:38 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o6G0hnJh029912 for <oauth@ietf.org>; Thu, 15 Jul 2010 17:43:49 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279241029; bh=lD78cindvK39niqkGFKkLZXw0S4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=b+SspwZOS205/m5BZIKY7T2NQ2J7FiF31t5UWXMxqVGSLH+GOhcT4HGvywz+BdoBt 12ZzEum14MBBnrHpmAXgg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=UFCNmXXRgkZu8u0v69Dv55EGmj1qOBTgEFpBqU4R73VeCn0WcGrFBpTBBzwOeljNy hxqqZvqPgA0RPQZdbhyRA==
Received: from iwn37 (iwn37.prod.google.com [10.241.68.101]) by kpbe20.cbf.corp.google.com with ESMTP id o6G0hQQU027166 for <oauth@ietf.org>; Thu, 15 Jul 2010 17:43:48 -0700
Received: by iwn37 with SMTP id 37so1838228iwn.21 for <oauth@ietf.org>; Thu, 15 Jul 2010 17:43:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.77.155 with SMTP id g27mr12972ibk.195.1279241027988; Thu, 15 Jul 2010 17:43:47 -0700 (PDT)
Received: by 10.231.130.9 with HTTP; Thu, 15 Jul 2010 17:43:47 -0700 (PDT)
Date: Thu, 15 Jul 2010 17:43:47 -0700
Message-ID: <AANLkTim7pvrLnQtz4WnDvYVRv0jbWgk3j8uMJj07CsM1@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=000e0cd254140e2de3048b768303
X-System-Of-Record: true
Subject: [OAUTH-WG] signatures, v2
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, 16 Jul 2010 00:43:40 -0000

Hi guys,

after reading through the feedback, we did a pass over the OAuth signature
proposals.

As a reminder, there are three documents:

- a document (called "JSON Tokens") that just explains how to sign something
and verify the signature:
http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

- an extension of JSON Tokens that can be used for signed OAuth
tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

- a different extension of JSON Tokens that can be used whenever the spec
calls for an "assertion":
http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
(When used in the assertion flow, this last token can also be used to do
"2-legged" OAuth)

A summary of the (scant) changes:

- we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you
double-check that that sounds good?
- we decided on unpadded websafe-base64 throughout.
- some changes to parameter names.
- some small changes I might be forgetting now...

As explained in my message to the previous thread, there is still no
envelope in there to help with encrypted tokens (b/c we don't understand
well enough what the envelopes for encrypted tokens would look like).

One question: What's the deal with having the signature go first? If you can
explain to me why that is a good idea, I'm happy to oblige.

Cheers,

Dirk & Marius.