Verifiable Messaging over HTTP

Problem: Figure out a simple way to enable a Web client or server to authenticate and authorize itself to do a REST API call. Do this in one HTTP round-trip.

There is a new specification that is making the rounds called HTTP Signatures. It enables a Web client or server to authenticate and authorize itself when doing a REST API call and only requires one HTTP round-trip to accomplish the feat. The meat of the spec is 5 pages long, and the technology is simple and awesome.

We’re working on this spec in the Web Payments group at the World Wide Web Consortium because it’s going to be a fundamental part of the payment architecture we’re building into the core of the Web. When you send money to or receive money from someone, you want to make sure that the transaction is secure. HTTP Signatures help to secure that financial transaction.

However, the really great thing about HTTP Signatures is that it can be applied anywhere password or OAuth-based authentication and authorization is used today. Passwords, and shared secrets in general, are increasingly becoming a problem on the Web. OAuth 2 sucks for a number of reasons. It’s time for something simpler and more powerful.

HTTP Signatures:

  1. Work over both HTTP and HTTPS. You don’t need to spend money on expensive SSL/TLS security certificates to use it.
  2. Protect messages sent over HTTP or HTTPS by digitally signing the contents, ensuring that the data cannot be tampered with in transit. In the case that HTTPS security is breached, it provides an additional layer of protection.
  3. Identify the signer and establish a certain level of authorization to perform actions over a REST API. It’s like OAuth, only way simpler.

When coupled with the Web Keys specification, HTTP Signatures:

  1. Provide a mechanism where the digital signature key does not need to be registered in advance with the server. The server can automatically discover the key from the message and determine what level of access the client should have.
  2. Enable a fully distributed Public Key Infrastructure for the Web. This opens up new ways to more securely communicate over the Web, which is timely considering the recent news concerning the PRISM surveillance program.

If you’re interested in learning more about HTTP Signatures, the meat of the spec is 5 pages long and is a pretty quick read. You can also read (or listen to) the meeting notes where we discuss the HTTP Signatures spec a week ago, or today. If you want to keep up with how the spec is progressing, join the Web Payments mailing list.

3 Comments

Got something to say? Feel free, I want to hear from you! Leave a Comment

  1. Laszlo says:

    Hi,

    I’ve been following a lot of the web crypto lated work of your group, as we’re also using a similar, yet in-house grown approach to sign HTTP requests. I have not analyzed the HTTP Signatures spec in details, but I’m not sure there is an easy way of getting the full serialized HTTP request in an browser-based javascript environment for signing.

    Have you tackled this issue in your discussions?

    Thanks.

    • ManuSporny says: (Author)

      Laszlo, it depends on how you do the request and if there are any proxies between you and the server, but I don’t really see anything preventing HTTP Signatures working from within the browser over XMLHttpRequest. What specific problems were you alluding to?

      You need to be able to get and set the headers, and you need to be able to get the body of the document. I’m pretty sure you can do both via XMLHttpRequest, no?

Trackbacks for this post

  1. Dew Drop – June 17, 2013 (#1,569) | Alvin Ashcraft's Morning Dew

Leave a Comment

Let us know your thoughts on this post but remember to play nicely folks!