[OAUTH-WG] Signatures...what are we trying to solve?

David Recordon <recordond@gmail.com> Tue, 28 September 2010 04:57 UTC

Return-Path: <recordond@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 482193A6C30 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 21:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id mAv4rp5v1Yx8 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 21:57:50 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id E10D23A67A5 for <oauth@ietf.org>; Mon, 27 Sep 2010 21:57:49 -0700 (PDT)
Received: by iwn3 with SMTP id 3so6397176iwn.31 for <oauth@ietf.org>; Mon, 27 Sep 2010 21:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rqje/Xk04rngArrATfIjwL9Uh/x6DmGlgblRSRvh/II=; b=X4pRnkMcCEHN1CxE8U4wf6twjGAk1kBdNwcanbVQbMCqqp74CnQHGvP87D1cpPzmuJ ToxYbnEK5tvRN/IWv4Suu4vZi/1vNkh0AxyHGIjUC3f9zDxoneg4kVEtQNIcynr96fHO 0RwonSfPvS1FmK9DEb3NIY/XWoVpejwQPNHQE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iZrjmSZ1JelqsCOcj2b21YT56rrNiz4vY+jq1OvhNBmBCdw+dwt6/15o2psCqwSgNx 2VoBv95L9bdJ+hwnd6D7dYPCnEfLYRrC/1+SarsJkY6W8KRcG9UgdiN1QQ3yut4YndBS y5NNnDIq0mR/2Q4clwak/d2EKxpQ3/W4e80Ns=
MIME-Version: 1.0
Received: by with SMTP id c12mr10046785iba.25.1285649909968; Mon, 27 Sep 2010 21:58:29 -0700 (PDT)
Received: by with HTTP; Mon, 27 Sep 2010 21:58:29 -0700 (PDT)
Date: Mon, 27 Sep 2010 21:58:29 -0700
Message-ID: <AANLkTimERshG-ndU8_uc0NJhx6ree6d8kxYj=EVeHpmA@mail.gmail.com>
From: David Recordon <recordond@gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="002215046ae330704904914ab282"
Subject: [OAUTH-WG] Signatures...what are we trying to solve?
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: Tue, 28 Sep 2010 04:57:52 -0000

If you know me then you'll know that I'm generally one of the last people to
talk about Alice and Bob. That said, there are a lot of technical proposals
flying across the list with very little shared understanding of the
problem(s) we're trying to solve.

>From what I've seen there are two distinct classes of signature use cases.
1) The first is where the HTTP request parameters must be part of the
signature. An example is any OAuth 1.0a style API where you want to make
sure that the HTTP POST your server just received isn't masquerading itself
as a GET.
2) The second is where the HTTP request is orthogonal. An example
is OpenSocial where the server is sending state information to the client
such as what user is currently logged in.

The main practical example I have of the first use case is what Twitter
wants to do with redelegation. In this case TweetDeck can't given TwitPic
it's own bearer token, but needs to sign the POST request and pass that
signature to TwitPic for it to include in the final API request to Twitter.

In terms of signing protected resource requests, I haven't heard anyone
bring up specific and detailed needs for this recently.

JSON tokens pretty clearly make sense for the second class of signature use
cases and it's actually a bit hard to argue why they would be a part of
OAuth. Facebook shipped this a bit over a month ago for canvas applications.
We include a `signed_request` parameter which is signature.base64url(JSON).
Parsing it is 18 lines of PHP.

This second class of use case will also be required by OpenID Connect where
the server is signing identity information and sending it to the client. I
imagine that OpenSocial will also still have it and wish to continue relying
on public key algorithms.

So a few questions:
 * Do we want to tackle both of these classes of signatures in OAuth?
 * Why do you consider the second class part of OAuth versus something
completely separate that might happen to include an OAuth access token?
 * Is the Twitter redelegation use case the right focus for the first class?
 * Is there an example of an OAuth 2.0 server that can't use bearer tokens
for protected resource requests and thus requires signatures?