W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Web Keys and HTTP Signatures

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 17 Apr 2013 17:32:17 -0400
Message-ID: <516F14E1.5040503@digitalbazaar.com>
To: Web Payments CG <public-webpayments@w3.org>
CC: ietf-http-wg@w3.org
We've implemented Joyent's (node.js) HTTP Signature specification using
the public key infrastructure defined by the PaySwarm Web Keys spec.
We're pretty happy with the solution given that this is the third
approach that we've tried to apply to the HTTP request signatures problem.

For those not familiar with Joyent's HTTP Signature specification, it's


The Web Keys (horribly outdated) spec is here:

The modification that has been made to Joyent's spec is to:

1. Use a Web Key URL for the keyId parameter, which changes Joyent's
   solution to depend on a Web-native, decentralized public key
2. Sign the request line, date, and host parameters by default to
   tighten up the default security requirements (to reduce, but not
   eliminate, replay attacks).

What this means is that you can now do signed HTTP requests like GETs on
specific resources in a fairly simple and decentralized way. It also
means that you can use the Web Key information to create an Access
Control List to HTTP-based resources and enforce both authentication and
authorization of GETs/POSTs/etc. in one HTTP call.

This feature has already been integrated into the request HTTP module in


We'll be releasing a few demos of how one can use this authorization
scheme with Web Keys in the next couple of weeks. We expect to integrate
these sorts of HTTP Signatures into the Web Keys specification.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
Received on Wednesday, 17 April 2013 21:32:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC