第2部分 自主管理身份技术

Arthur C. Clarke 说过：“任何先进的技术都魔力非凡。”在第 1 部分中，我们介绍了自主管理身份的基本组成部分，这些组成部分对于非技术人员来说很容易理解。在第 2 部分中，我们将深入了解这些组成部分，并了解如何将它们组合在一起来实现自主管理身份的“魔力”。

◎第 5 章总体概述了自主管理身份的架构，以及自主管理身份架构师面临的一些关键设计选择。

◎第 6 章解释了为什么自主管理身份是“全程加密”，并介绍了加密技术的创新使自主管理身份成为可能。

◎第 7 章是一部小型教科书，介绍“自主管理身份秀之星：可验证凭证”。这是全书唯一一章涉及代码的——作为 W3C 可验证凭证数据模型 1.0 规范核心的 JSON 和JSON-LD 数据结构的示例。

◎第 8 章深入探讨了自主管理身份的另一个基础开源标准：W3C 分布式标识核心规范，其中深入分析了分布式标识如何解决传统公钥基础设施中最难的问题。

◎第 9 章涉及自主管理身份用户手中的两大工具—数字钱包和数字代理，并介绍了从第一代实施者那里汲取的经验教训。

◎第 10 章进一步深入探讨自主管理身份的核心——分布式加密密钥管理，全面分析该领域最重要的创新：密钥事件接收基础设施。

◎第 11 章解释为什么“治理框架”将这些不同的新技术融合起来，并为现实社会带来实惠，即为商业、法律和社会政策提供“黏合剂”的治理框架（又称信任框架）。

第5章 SSI架构：大局观

第 1 部分介绍了 SSI 的基本组成部分、实例场景、功能和优点，而本章把这些内容置于 SSI 架构的总体架构中。正如我们将不断重复的话—SSI 是年轻的，许多方面仍在不断发展。尽管如此，基本分层和几个关键的基础标准已经出现，所以主要问题是如何实施这些标准，以及具体的设计选择在多大程度上决定互操作性。在本章中，Daniel Hardman—Evernym 的前首席架构师兼首席信息安全官，现任 SICPA 的首席生态系统工程师，也是这里所讨论的大多数核心标准和协议的贡献者，将带领你浏览 SSI 架构的 4层范式、每一层的关键组件和技术，以及整个堆栈中架构师和实施者所面临的关键设计决策。本章为第 2 部分的其他章节奠定了基础，后续章节将更深入地探讨具体的 SSI 技术。

第 2 章讨论了 SSI 的基本组成部分，这些组成部分体现了重要的共性。然而，就像二十世纪初的汽车设计一样，年轻的市场在细节上产生了许多创新和分歧：有些发明有 2 个轮子，有些发明有 3 个或 4 个轮子；一些人青睐蒸汽，而另一些人则喜欢以汽油或柴油作为动

力的内燃机。

在本章中，我们将认识分布式数字身份架构中的重要决策点、每个决策点上值得注意的选项，及其带来的好处和挑战。

5.1　SSI堆栈

SSI 堆栈有些差异的类型无关紧要，而有些则是根本性的。区分这些差异的类型是 SSI架构师的一个重要主题，因为它影响互操作性。

2018 年 10 月，互联网身份研讨会首次尝试描述SSI堆栈中的所有关键选项。参会者列出了可能出现在SSI解决方案中的11个技术层，并描述了它们之间的依赖关系。然而，后来的经验表明，这比描述 SSI 中基本架构依赖关系所需的粒度更为精细。2019 年，来自不同背景的SSI 架构师在 Hyperledger Aries 项目中共同提出了图 5.1 所示的 4 层模型，我们在本章中使用了该模型。底层虽然重要，但本质上是看

不见的支撑；顶层体现了普通用户可见的概念，这些概念直接与业务流程、监管策略和法律管辖相关联。

这些层中的每一层都体现了关键架构决策，并且每一层都对互操作性有重大影响。在本章的其余部分，我们将从下往上构建，详细讨论每一层。

5.2　第1层：标识符和密钥

第 1 层是堆栈的底部，在这里定义和管理标识符和密钥。这些通常被称为可信根，就像真正的树一样，根越坚固，树也就越坚固。这一层需要保证所有涉众都同意相同的事实，即标识符引用了什么，以及如何使用加密密钥来证明对该标识符的控制。它还必须允许生态系统中的每一方在不依赖或不受中央机构干预的情况下读写数据—这一属性在区块链社区中被广泛称为抗审查性。

SSI 社区普遍认为，提供这些性能的最佳方法是公开一个可验证数据注册系统，也称为分布式标识（DID）注册系统或 DID 网络，因为它是分布式标识的真相来源（DID 已经在第2 章做过简要介绍，在第 8 章将进行详细描述）。每个 DID 注册系统使用一种 DID 方法，该方法定义了与特定类型的 DID 注册系统交互的特定协议。虽然这种方法把第 1 层所需的总体抽象性标准化了，但仍然允许在细节上有很大的差异。

（1）实施 DID 注册系统的最佳方式是什么？应该允许还是不允许？应该如何治理？它的规模有多大？

（2）到底应该如何在这个 DID 注册系统上注册、查找和验证 DID，以确保它们在保护隐私的同时是安全的？

（3）DID 注册系统上还需要存储哪些数据来支持 SSI 堆栈的上层？

正如第 8 章将要讨论的，在 W3C DID 工作组（did-spec-registries）维护的 DID 注册系统中定义了 80 多种 DID 方法，将来可能还会有更多的方法，这反映了迄今为止开发的 DID方法的多样性。在本节中，我们将讨论它们所属的主要架构类别。

5.2.1　用区块链实现DID注册系统

正如本书开头提到的，SSI 的诞生是由于区块链技术引入了一个令人兴奋的新选项，用于实现分布式公钥基础设施（第 6 章将对此进行更详细的解释）。这反过来可以解锁可验证凭证的能力（如第 7 章所述）。因此，区块链因其有多种形式成为 SSI 堆栈第 1层的首选。截至本书编写时，W3C 的 DID 注册系统中 90% 以上的 DID 方法都基于区块链或分布式账本技术，其中，还包括许可账本（例如，超级账本 Indy)、分布式有向无环图和分布式散列表。尽管专家们对如何准确应用这些技术存在争议，但区块链已经成为它们的一般总称。原则上，按照我们在本章中描述的架构，预计所有这些技术都应该能够实现 SSI的设计目标。

然而，这些区块链的关注点也有所不同，包括以下几项。

（1）作为身份问题，它们对参与工作流程的各项整合程度如何（如果有）？

（2）身份操作是区块链的首要特征，还是只在某些情况下会与身份有交叉的一般特征（例如，智能合约）？

（3）它们运营和规模的成本是多少？

（4）它们能提供多少时延和吞吐量？

（5）它们是如何被允许和管理的？

（6）它们如何处理监管合规性和审查阻力？

总之，最好将区块链视为满足第 1 层要求的一个选项，但不是唯一的选项，也不一定是最好的选项，而这取决于区块链的设计和实现，以及使用该区块链的具体 DID 方法的设计和实现。

（1）使用成本高得令人望而却步的区块链可能会让世界上许多弱势群体用不起 SSI。

（2）发展太慢的区块链可能永远不会被采用。

（3）获得许可的区块链可能不足以消除人们对审查阻力的担忧。

（4）如果区块链代码库被一小部分人严格控制，人们可能会认为它不够可信而不会广泛采用。

接下来让我们具体了解区块链的两个主要分支：通用公共区块链和专用区块链。

5.2.2　适用于SSI的通用公共区块链

区块链技术虽然诞生时间不久，但已经有了比特币和以太坊两大“祖师爷”。因此，它有着优越的稳定性并且成为众多开发商的首选，而要在公共基础设施中产生信任，则少不了开发商的支持。这就解释了为什么 Learning Machine（比特币）和 uPort（以太坊）（最早实现SSI 的两个企业）是以这些区块链技术为目标的，也解释了为什么在 W3C 的 DID 注册系统中注册的十几种 DID 方法被用于比特币或以太坊。

这些方法的共同点是，它们使用账本上交易的加密地址（即支付地址）作为 DID。支付地址已经是不透明的字符串，它全球唯一，并由密钥管理。尽管由 Learning Machine 倡导的 Blockcerts 教育凭证标准早于 W3C 的可验证凭证和 DID 标准，但它是基于这种方法构建的，在此基础上，凭证发行和验证（第 3 层）工作良好。

然而，支付地址没有丰富的元数据，也没有提供与地址持有者联系的方式，这将交互限制在一个“不要打电话给我们，我们会打电话给你”的模型中。支付地址也是全局关联者，这导致了隐私问题。

5.2.3　为SSI设计的专用区块链

2016 年，开发人员当时正在创建第一个明确为支持 SSI 而设计的区块链。第一个设计来自 Evernym，它为公共许可账本开发了一个开源代码库，其中所有的节点都将由可信机构操作。Evernym 帮助 Sovrin 基金会成为区块链领域的非营利权限治理机构，然后将开源代码贡献给了基金会。

Sovrin 基金会随后将开源代码贡献给了由 Linux 基金会主持的超级账本（Hyperledger）项目，成就了现在的 Hyperledger Indy 项目。Hyperledger Indy 加入了其他面向业务的超级账本区块链操作系统，包括 Fabric、Sawtooth 和 Iroha。作为唯一专门为 SSI 设计的超级账本项目，Hyperledger Indy 代码库现在由公共许可的 SSI 网络运行，其节点包括世界上最大的非营利小额贷款平台Kiva。

专用区块链的下一个参与者是 Veres One，由 Digital Bazaar 创建。它是一个共有许可区块链，优化后用于在 JSON-LD 中存储 DID 和 DID 文档，JSON-LD 是一种基于资源描述框架（RDF）的丰富语义图格式。Veres One 区块链正被用于多个 SSI 试点，涉及供应链和溯源的可验证凭证。

专门为 SSI 构建的区块链的交易和记录类型可以使 DID 管理变得更容易，如 Veres One和 Hyperledger Indy。然而，第 1 层不仅仅有 DID。Hyperledger Indy 代码库支持由 W3C 可验证凭证数据模型 1.0 和 Hyperledger Aries 开源代码库支持的 ZKP 凭证格式。ZKP 凭证在第 1 层需要如下几个加密原语。

（1）“模式”（Schemas）—这是发证方定义它们希望包含在可验证凭证中的声明（属性）的方式。将“模式”定义放在公共区块链上，让它们可供所有验证方检查，以确定语义互操作性（跨孤岛数据共享的临界点）。

（2）“凭证定义”（Credential Definitions）—“凭证定义”与“模式”的区别在于，凭证书定义发布在账本上，以声明具体要求、公钥和其他元数据，这些数据将由特定的发证方用于特定版本的可验证凭证。

（3）“撤销注册”（Revocation Registries）—这是一种特殊的数据结构，称为加密累加器，用于尊重隐私的可验证凭证的撤销。想了解更多细节，请参见第 6 章。

（4）“代理授权注册”（Agent Authorization Registries）—这是一种不同类型的加密累加器，用于提升 SSI 基础设施的安全性。它可以授权和撤销授权特定设备上的特定数字钱包，例如，当它们丢失、被盗或被黑客攻击时，则撤销对其授权。

注：“语义互操作性”（Semantic Interoperability）是计算机系统以明确、共享的意义交换数据的能力。语义互操作性不仅涉及数据的包装（语法），同时还涉及数据含义传输（语义）。这是通过添加用来“描述数据的数据—元数据”，将每个数据元素与受控的共享词汇表链接起来实现的。

同样重要的是账本上的任何私人数据。尽管基于区块链的身份识别早期实验提出了一个概念，即把个人凭证和个人数据作为加密数据对象直接放在区块链上，但由随后的研究和分析得出了这是一个坏主意的结论。首先，所有加密都寿命有限，将私有数据写入不可变的公共账本有可能最终被破解，即便账本本身使用的加密技术已经升级，亦有此可能。其次，即使是加密的数据，仅仅通过观察谁写和谁读也会存在隐私问题。最后，欧盟 GDPR 和全球其他数据保护条例的重大问题被提出，这些条例为数据主体提供了“擦除权”（详细分析见 Sovrin 基金会关于 GDPR 和 SSI 的白皮书——Data Protection and the Sovrin Governance Framework）

5.2.4　用传统数据库实现DID注册系统

尽管这似乎与分布式的方法背道而驰，但互联网巨头的用户数据库已经表明，现代网络用数据库技术可以实现 DID 注册系统所需的鲁棒性、全球规模应用和地理分布式。一些人甚至提议，像脸书这样的大规模社交网络数据库，或者像印度的 Aadhaar 这样的政府身份数据库可以成为快速采用 DID 的基础，因为它们具有广泛的覆盖范围、经证明的易用性和现成的应用案例。

然而，这类数据库既不是自主的，又不具备抗审查性。对这些数据库的信任植根于集中管理者，他们的利益可能与他们所发现的个人利益不一致。当第三方更新每一次登录或交互时会存在隐私问题，无论经营它们的组织是政府、私营企业，还是慈善机构。这种集中化破坏了 SSI（以及互联网）最重要的设计目标之一：消除单点控制和故障。因此，大多数 SSI 工作者不会把传统的数据库作为第 1 层的可行实现途径。

5.2.5　用对等协议（peer to peer）实现DID注册系统

随着 DID 方法的成熟，SSI 架构师已经意识到有一类 DID 不需要在后端区块链或数据库中注册，相反，这些 DID 和 DID 文档可以在需要其相互识别和认证的对等方之间直接生成和交换。

在这种情况下，“DID 注册中心”是每个对等 DID 的数字钱包（每个对等方是另一个“可信根”），且可用于交换这些对等 DID 协议中的信任。这种对等 DID 方法不仅具有比区块链或基于数据库的 DID 方法更好的性能，而且它还意味着 DID、公钥和服务端点是完全私有的，它们永远不需要与任何外部方共享，更不用说在公共区块链上共享了。

点对点 DID 方法，称为对等 DID（did:peer:），起初在 Hyperledger Aries 项目的赞助下启动，然后转移到分布式身份基金会。对等DID直接在两个相关对等方的数字钱包中生成，并使用其数字代理进行交换，因此，实际上对等 DID 是完全在 SSI 堆栈的第 2 层实现了第 1

层的解决方案。但是，对等 DID 方法正在为以下情况开发后备解决方案：一个或两个对等方（例如，由移动电话代表的两个人）移动到新的服务端点（例如新的移动电话运营商）并彼此失去联系。

“三重签名收据”是另一个协议的范例，该协议也在没有任何区块链的情况下解决了以上问题。它最初被描述为标准复式记账的演变，但也可用于解决身份方面的双重支付问题（例如，向一方声称某个密钥已授权，而向另一方声称某个密钥未授权）。协议中的每一方都签署了一个交易描述，该描述不仅包括输入值，还包括输出值（产生的余额）。外部审计师也会签字。一旦三个签名全部累加起来，交易的真实性就没有问题了，因为签署的数据除输入值外，还包括最终余额，所以不需要查阅以前的交易就可知道交易结果。

密钥事件接收基础设施（KERI）是一个完整的便携式 DID 架构，是围绕对等 DID 核心的自认证标识符概念开发的。KERI 进一步定义了相应的分布式密钥管理架构，详情见第10 章。

预计未来几年内，我们将针对第 1 层功能开发出更多的基于对等协议的解决方案，所有这些都将增强 SSI 堆栈基础层的整体强度。

5.3　第2层：安全通信和接口

如果第 1 层是关于建立分布式的可信根（无论是可公开验证的还是对等的）的，那么第2 层就是关于如何依赖这些可信根在对等方之间建立安全通信，这一层也是我们在第 2 章中介绍的数字代理、数字钱包和加密数据存储所在的层，还是安全的 DID 到 DID 连接形成的层。

尽管所有类型的参与者，包括人、组织和事物都由第 2 层的这些数字代理和钱包来表示，但在这一层的这些参与者之间建立的信任仍然只是密码学上的信任，换句话说，这种信任包括以下情况。

（1） DID 由另一个对等方控制。

（2） DID 到 DID 连接是安全的。

（3）通过连接，发送的消息是真实的，没有被篡改。

这些都是建立人与人之间信任的必要条件，但并不充分，因为它们还没有建立关于 DID识别的人、组织或事物的任何信息。例如，DID 到 DID 的连接并不关心远端方是否道德、诚实或合格，而只关心是否能以防篡改和保密的方式进行交流。为此，我们必须上升到第 3 层和第 4 层。

第 2 层的架构问题主要分为两类：协议设计和接口设计。本节讨论两种主要的协议设计方案，以及 3 种主要的接口设计方案。

5.3.1　协议设计方案

协议是互联网本身的核心，TCP/IP 堆栈使互联网得以实现，而超文本传输协议（HTTP）和超文本传输安全协议（HTTPS）使网站得以实现。对于 SSI，协议设计至关重要，因为它定义了数字代理、数字钱包和交换中心通信的规则。

SSI 社区正在努力实现两种主要的协议设计架构。

（1）基于网站的协议设计遵循 W3C 经典的《万维网架构》文档中详述的相同的基本HTTP 模式，这种方法特别依赖 HTTPS 中使用的传输层安全性（TLS）协议。（业内广泛认为《万维网架构》是网站架构的“指南”。）

（2）基于消息的协议设计使用 DIDComm 协议进行数字代理之间的对等通信，这种架构方式更类似于电子邮件。

1. 用 TLS 实现基于网站的协议设计

第一种方法以简单的观察为基础：我们已经有了普遍存在、稳健的安全网站通信机制，其形式是 TLS 协议。那么，为什么还要重复创造协议呢？

该观点的支持者正在构建一个系统，其中各方通过 RESTful 网络服务调用来相互交流。这类机制的工具和库很容易被人们理解，并且数百万开发人员对其很满意，其开发过程也相对容易。

然而，这种方法依然存在以下挑战。

（1）虽然 TLS 可以应用于其他协议，但主要成功应用还是在 HTTP 上。这意味着，只

有当至少一方运行网站服务器时，才能直接响应 TLS。

（2）本质上是双方的（客户端和服务器）。

（3）需要一个相对直接的请求 - 响应范式交互，还需要双方同时在线。

（4）服务器是被动的；当被调用时，它会做出反应，并可以触发网络钩子（Webhook）或回调统一资源定位符（URL），但它不能自行联系对方，除非对方也在运行网站服务器。

（5） TLS 的安全模型是非对称的：服务器使用 X.509 数字凭证（第 2 章已介绍，第 8 章将详细讨论），客户端使用密码、API 密钥或 OAuth 令牌。这往往会导致权力不平衡持续下去，即拥有高信誉服务器证书的组织决定低信誉客户端的行为。这与 SSI 中的点对点分布式理念背道而驰。它还使 DID 及其密钥的控制成为次要的，甚至是多余的。

（6）隐私和安全保障不完善。SSL 可见性设备是众所周知的黑客工具，它为通过机构局域网（LAN）运行的每个 TLS 会话插入中间人。X.509 证书颁发机构由人操作，可以被人利用，并且 TLS 无法保护静止或安全信道之外的通信数据。

因此，尽管有大量的 SSI 代码开发遵循使用 HTTPS 的传统网站架构路径，但在更具包容性的方法中，投入了至少同样多，甚至更多的开发工作。

2. 用 DIDComm 实现基于消息的协议设计

第二种方法称为 DIDComm（DID Communication 的缩写）。它将第 2 层设想为面向消息、与传输无关，并植根于对等方之间的交互。在这种范式中，数字代理之间的通信在概念上类似于电子邮件，它本质上是异步的，可能涉及同时向多方广播，其传递是尽力而为的，回复可能通过不同的渠道到达。

注：从架构的角度来看，DIDComm 与当今许多安全消息应用程序使用的专有协议有许多共同点。它甚至支持类似的分组结构。然而，它也有一些不同之处。它的 DID 基础让它可以点对点工作，而不需要所有的流量通过集中服务器路由。它侧重于传递机器可读而非人可读的信息，这使得它涉及的问题不限于安全聊天方面。软件使用 DIDComm 消息来促进机构与物联网设备，以及人与人之间的各种可能的交互，这意味着 DIDComm 的一些用户可能认为这种交互与传统的安全消息应用程序并不相似。

然而，DIDComm 与简单邮件传输协议（SMTP）的不同之处如下。

（1）收件人由 DID 而不是电子邮件地址标记。

（2）所有通信都有与 DID 相关联的密钥保护（加密、签名或两者兼而有之）。即使是静止的数据，也是如此。

（3）消息可以通过任何传输方式传递：HTTP、蓝牙、ZMQ（Zero Message Queuing）、文件系统 / 球鞋网络（Sneakernet）、高级消息队列协议（AMQP）、移动推送通知、二维码、套接口、文件传输协议（FTP）、SMTP、蜗牛邮件（Snail mail）等。

（4）无论以何种方式传输，安全和隐私保证都是一样的。一条路线可以使用多种传输方式。

（5）由于传输有独立性，因此，传输的安全性也是可移植的。也就是说，双方可以部分使用来自供应商 A 和 B 的专有工具通过电子邮件进行交互，部分通过由供应商 C 控制的基于社交媒体的聊天进行交互，部分通过使用多个移动提供商的短信息服务（SMS）进行交互。然而，只需要两组密钥（每一方的 DID 密钥）来保护所有前文提到的那些情况下的交互，交互历史与 DID 相关，而与通道无关。有通道的供应商不能通过拥有安全性来强制锁定。

（6）路由是适应隐私的；DIDComm 的设计使得中介无法知晓消息的最终来源或最终目的地，只知道下一跳地址，因此允许（但不要求）使用混合网络和类似的隐私工具。

在请求 - 响应范式中，DIDComm 可以很容易地使用 HTTP 或 HTTPS，因此这种协议设计方法是基于网站方法的一个超集。但是，DIDComm 为其他情况提供了灵活性，包括一方只是偶尔连接或通道包含许多不受信任的中间人的情况。

DIDComm 最重要的技术弱点是它的新颖性。尽管世界上的网站开发人员使用的工具（CURL、Wireshark、Chrome、Swagger 等开发工具）与 DIDComm 相关并对其有所帮助，但对于 DIDComm 工具的本质还不成熟。因此，在 SSI 生态系统的早期，选择DIDComm 所花费的成本较高。

尽管如此，DIDComm 的势头正在迅速增强。虽然它最初是在超级账本开发者社区中孵化的，但到了 2019 年 12 月，人们对超级账本之外的兴趣日益增长，因此 DIDComm 工作组成立了分布式身份基金会。对不同的编程语言来说，DIDComm 的不同部分已经有十几种实现方式。