Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News A Proposal for an HTTP Digital Signature Protocol and API

A Proposal for an HTTP Digital Signature Protocol and API

This item in japanese


Digital Signatures are coming back after more than a decade of little adoption. The main reason for this come back is the emergence of composite applications (a.k.a converged applications in the mobile world). Composite Applications are quite an architecture feast, they are built with parts and services under different domains of ownership, by different teams, with different release cycles, different technologies, scalability, availability or security models.

One of the core problems in composite applications is trust. All parts and services working together to deliver a common solution (and they often participate in a broad range of solutions altogether) need to trust each other from and identity and access rights perspective. With that in mind, one of the core problems of HTTP is that its authentication mechanisms assumes a single identity (the one of the user, or a server) validated by the request handler. HTTP has the greatest difficulty to establish all identities of the parties involved in marshalling the request (a user, using a hick or thin client of an application build by developer X). This scenario is increasingly common these days as large "Independent Services Vendors" expose trusted their services to pretty much any developer on the planet. The question becomes then, how can HTTP carry the identity of the user, the client and the applicaiton (type) or developer who built the application?

Bill Burke developed a proposal to extend the HTTP protocol to support Digital Signatures and the corresponding set of APIs in REST Easy . He explains:

OAuth does have signatures as part of its protocol, but I wanted something that was orthogonal to authentication as the client and server may not be using OAuth for authentication.)

The protocol goals and features we wanted to have were:

  • Simplicity of headers.  Have all signature information be stored within HTTP request or response headers.  This makes it easier for frameworks and client and server code in general to handle signature verification.
  • Expiration.  We wanted the ability to expire signatures.
  • Signer information.  We wanted the ability to know who signed the message.  This would allow receivers to look up verification keys within internal registries.
  • Ability to ignore the signature if you don’t care about that information.
  • Ability to forward message and request to multiple endpoints/receivers
  • Allow multiple different URLs to publish the same signed message
  • It is not meant to replace existing OAuth or Digest protocols that ensure message integrity 

One of the key advantages of DSig-based protocols is the ability to both assert identity and create a tamper-proof envelope of the content of the message which are often both required together.

Bill suggests to create a specific Content-Signature HTTP header that could look like this:

Content-Signature: type=redhat;
                   expiration="Sunday, 06-Nov-11 08:49:37 GMT";

The question really, is not so much how to adapt HTTP include a digital signature protocol, this is just a "message envelope" problem, it is rather "How will the industry solve the problems that have prevented the adoption of DSign?" In particular the interoperability problems. Do you see the need for augmented authentication and tamper proof mechanisms in HTTP? Which solutions do you see emerging?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • New or Ignorance?

    by Bill Burke,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    FYI, I wrote this blog after I was looking for HTTP-based message signing protocols and formats. I did see multipart/signed. But if you take a look at this blog, it gives some good reasons why a envelope format isn't the best. I also couldn't find a protocol/format/whatever that allowed you to describe what was used to calculate the signature. I wanted to have expiration, timestamp, and signer be optional components of the signature beyond the body as well as allow the user to add any additional components they wanted. If there is a better or predefined RFC on something very similar to this, I would definitely use it instead of creating yet another signature protocol. It must meet the goals of what I'm trying to accomplish here though.

    Why do this? Firstly, a Resteasy user wanted the ability to sign representations that may be forwarded to multiple parties. Secondly, I'm looking for a more easily managed way to secure HornetQ REST if you decided to run it as a broker/SaaS (Service as a Service).

    I'm also wondering if a header-based approach to body-encryption might be interesting as well as an alternative to multipart/encrypted.

    Finally, for any of these new approaches to be adopted, popular languages are going to need to support it without much effort. I know I can do all this stuff in Java easily. I will be looking into Python and Ruby as well. It seems though they have decent crypto libaries.

    Thanks for any feedback.

    Bill Burke
    JBoss, by RedHat

  • Re: New or Ignorance?

    by Rodd Schlerf,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Good article Bill. I would argue a little bit, however, about little adoption in past decade. If you look at certain industries such as the FDA regulated markets, or government in general, the digital signature market has grown rather rapidly and substantially over the past 5 years.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p