[apps-discuss] Web Keys and HTTP Signatures

Manu Sporny <msporny@digitalbazaar.com> Thu, 18 April 2013 21:27 UTC

Return-Path: <msporny@digitalbazaar.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8A41B21F90EB; Thu, 18 Apr 2013 14:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.497
X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=-5.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QcGV3lQfD4ta; Thu, 18 Apr 2013 14:27:12 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown []) by ietfa.amsl.com (Postfix) with ESMTP id D87F121F90CC; Thu, 18 Apr 2013 14:27:12 -0700 (PDT)
Received: from zoe.digitalbazaar.com ([] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1USwMK-00028p-03; Thu, 18 Apr 2013 17:27:12 -0400
Message-ID: <5170652F.60609@digitalbazaar.com>
Date: Thu, 18 Apr 2013 17:27:11 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5
MIME-Version: 1.0
To: IETF HTTP Auth <http-auth@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 19 Apr 2013 08:10:09 -0700
Cc: Web Payments CG <public-webpayments@w3.org>
Subject: [apps-discuss] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 21:29:05 -0000

My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
of various W3C specs and member of the HTML WG and RDF WG.

There is a relatively new spec at W3C called Web Keys[1] that now
supports HTTP Signatures[2]. It is being worked on as a part of the Web
Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
Keys and HTTP request signatures.

We'd like to coordinate with the IETF on this work to make sure we have
all parties interested in solving this problem involved in the work. We
would also like more eyes doing security audits[5] on the protocol.

For a high-level introduction to Web Keys, see the Mozilla Hacks article:


For a high-level introduction to the Web Payments work, look here:


One of the first questions that came up in the IETF HTTP WG thread[5] on
the matter is why none of the other HTTP authentication schemes were
acceptable to the Web Payments group at W3C. Here is a quick run-down of
the reasoning:

HTTP Origin-Bound Authentication (HOBA)

We had considered signatures in the URL in the second approach to the
problem in the Web Keys spec. We eventually rejected the solution
because of limitations in the URL length in some browsers and because we
wanted the semantics of the HTTP headers to be able to be a part of the
digital signature. We also didn't want large signed messages being
dumped to the webserver logs (the request line is typically included).
So, while HOBA does solve the problem, it doesn't solve it in a way that
is acceptable to us.

HTTP Mutual Authentication

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.


This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

I'll stop here and wait for feedback from the groups that are involved.
I am in contact with Stephen Farrell and a few other folks at IETF about
where best to coordinate the work.

-- manu

[1] https://payswarm.com/specs/source/web-keys/
[3] http://www.w3.org/community/webpayments/
[4] https://payswarm.com/
[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0145.html

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch