针对HTTP数字签名协议和API的提议

　　数字签名在遭遇十年多的冷遇后重新回到了我们的视野。这次回归归因于复合应用的出现，复合应用在移动领域中又称为聚合应用。复合应用是一场架构的盛宴，组成复合应用的部分和服务分属不同拥有者的不同域，由不同的团队开发，有着不同的发布周期，使用不同的技术，具有不同的伸缩性、可用性或安全模型。

　　信任是复合应用的核心问题之一。从身份识别和访问权限的角度来说，所有协同工作的部分和服务都需要彼此信任，以便交付共同的解决方案，这些部分和服务也经常会组成涉及范围颇广的解决方案。鉴于此，HTTP的核心问题之一就是，HTTP的认证机制会假定一个由请求处理器验证的单一身份（一个用户或一台服务器）。这样，建立请求涉及各方的身份识别就是HTTP最大的困难，比如使用应用胖/瘦客户端的用户、构建应用的某开发人员。随着大型“独立供应商”将他们受信任的服务逐渐暴露给几乎所有的开发人员，这种情况变得越来越普遍。问题继而成为，HTTP该如何附带用户、客户端、应用（类型）或应用开发人员的身份识别信息？

　　Bill Burke提议对HTTP协议进行扩展，以支持数字签名和RESTEasy里对应的API。他解释道：

签名确实是OAuth协议的一部分，但我曾经希望与认证互相垂直的某些内容能作为客户端、而服务器可以不用OAuth进行认证。 我们希望协议能具备以下目标和功能：

• 简单的头信息。所有的签名信息都存储在HTTP请求或响应头中。这通常能简化框架、客户端、服务器代码对签名的验证。
• 过期。我们希望能让签名过期。
• 签名者的信息。我们想知道是谁对消息进行了签名。这可以让接收者在内部注册表里查找验证键值。
• 你要是不关心签名信息，可以忽略它。
• 可以将消息和请求转发到多个端点或接收者。
• 允许多个不同的URL发布相同的签名消息。
• 这并不意味着要去取代能保证消息完整性的OAuth或Digest协议。

　　基于DSig的协议有个很主要的优势——断定身份的同时还能创建消息内容的防篡改信封，这两个功能通常都要求同时出现。

　　Bill建议创建一个特定的HTTP头Content-Signature，示例如下：

Content-Signature: type=redhat;
values=signer:expiration;
headers=Content-Type:Date;
signer=bill;
expiration="Sunday， 06-Nov-11 08:49:37 GMT";
signature=0f341265ffa32211333f6ab2d1

　　真正的问题与其说是如何采用包含数字签名的HTTP协议（这仅仅是个“消息信封”的问题），还不如说是“业界该如何解决阻碍DSig推广的问题”，特别是互操作性问题。你有没有发现对HTTP里的认证和防篡改机制有了越来越多的需求？你找到什么解决方案了么？

　　查看英文原文：A Proposal for an HTTP Digital Signature Protocol and API