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;
values=signer:expiration;
headers=Content-Type:Date;
signer=bill;
expiration="Sunday, 06-Nov-11 08:49:37 GMT";
signature=0f341265ffa32211333f6ab2d1
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?
