数字签名在遭遇十年多的冷遇后重新回到了我们的视野。这次回归归因于复合应用的出现，复合应用在移动领域中又称为聚合应用。复合应用是一场架构的盛宴，组成复合应用的部分和服务分属不同拥有者的不同域，由不同的团队开发，有着不同的发布周期，使用不同的技术，具有不同的伸缩性、可用性或安全模型。
信任是复合应用的核心问题之一。从身份识别和访问权限的角度来说，所有协同工作的部分和服务都需要彼此信任，以便交付共同的解决方案，这些部分和服务也经常会组成涉及范围颇广的解决方案。鉴于此，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
注册/登录 InfoQ 发表评论