HTTP Signatures specification updated

In order to make Web Payments (and REST APIs in general) more secure on
the Web, this group has been working on extensions to the HTTP protocol
so that you can digitally sign HTTP headers and content.

We just pushed an update to the specification and believe that it's
ready for public comment. The specification is already deployed in
production at Joyent and Digital Bazaar:

http://tools.ietf.org/html/draft-cavage-http-signatures-01

This technology is useful when you just need to make a secure request to
your financial provider to transmit money from you to someone else, make
a payment, create an invoice, etc. without having to perform a login
handshake (OAuth, user+pass, etc.).

This is what a payment request looks like using this specification:

POST /transactions HTTP/1.1
Host: payments.example.com
Date: Sat, 01 Feb 2014 21:31:40 GMT
Content-type: application/ld+json
Digest: SHA-256=ZjQ1MjU1ZWNhNWUwZWM4N2...yAqdGVzdAo=
Content-length: 525
Authorization: Signature
  keyId="http://bluebank.com/people/john/keys/5",
  algorithm="rsa-sha256",
  headers="request-line host date content-type digest content-length",
  signature="jgSqYK0yKc...ZZItOuhIs78w="

{
  "@context": "https://w3id.org/payswarm/v1",
  "type": "Transaction"
  "transfer": {
    "type": "Transfer",
    "amount": "7.50",
    "currency": "USD",
    "source": "https://bluebank.com/people/john/accounts/party-funds",
    "destination": "https://redbank.com/people/jane/accounts/hosting",
    "comment": "Chipping in for the Pizza Party tomorrow."
  },
  "signature": {
    "type": "GraphSignature2013",
    "created": "2011-09-23T20:21:34Z",
    "signer": "http://bluebank.com/people/john/keys/5",
    "signatureValue": "ExMgoDIyOGQzNGVkMzVmmM...yZTkZDYMI="
  }
}

An astute reader might recognize that there are two signatures in this
request. The first one is on the HTTP message, the second one is on the
transaction. This is done because the first signature is designed to
authenticate the client (person or organization making the call). The
second signature is designed to authenticate the request (which may have
been made by a different person or organization than the entity making
the request). This dual-signature approach allows agents to relay
financial requests on behalf of other people or organizations. One
optimization would be to remove the signature in the message so that
only one signature is necessary for this type of transaction.

The HTTP Signatures specification is utilized by the Web Payments
specification, the Secure Messaging specification, and the Web Identity
specification, which are then used by most every other specification
that this group is working on that requires REST API authentication.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

Received on Saturday, 1 February 2014 18:54:29 UTC