2 of 7

SSI堆栈

SSI架构图

分歧

有些类型的分歧是无关紧要的；有些则是根本性的。将两者分开是SSI架构师之间的一个重要话题，因为它影响到互操作性。

�互操作性

SSI架构图中的每一层都体现了关键的架构决策，每一层都对互操作性有重大影响。

3 of 7

第1层：标识符和公钥

点对点协议作为DID注册表。

常规数据库用作DID注册表。

为SSI设计的特殊用途的区块链。

区块链用作DID注册表。

将通用公共区块链应用于SSI。

每个DID注册表都使用一种DID方法，该方法定义了与该特定类型的DID注册表互动的特定协议

第1层是堆栈的底部，在这里定义和管理标识符和公钥。这些通常被称为信任根，像真正的树一样，根越强，树越强。这一层需要保证所有的利益相关者都同意相同的事实，即标识符所指的是什么，以及如何使用加密钥匙来证明对该标识符的控制。它还必须允许生态系统中的每一方在不依赖或不受中央当局干扰的情况下读取和写入数据--这一属性在区块链社区被广泛称为抗审查。

在SSI社区中有一个广泛的共识，即提供这些特性的最佳方法是公开一个可验证的数据注册表(也称为DID注册表或DID网络，因为它是去中心化标识符(DIDs，在第2章中介绍，在第8章中详细描述)。每个DID注册表使用一个DID方法，该方法定义了一个特定的协议，用于与特定类型的DID注册表交互。虽然这标准化了Layer 1所需的总体抽象，但这种方法仍然允许在细节上有很大的变化。例如:

实施去中心化系统的最佳方式是什么？它应该是许可的还是无许可的？它应该如何管理？它的规模有多大？
究竟应该如何在这个去中心化的系统中注册、查询和验证DID，以确保它们是安全的，同时仍然保护隐私？
还有哪些数据需要存储在分散的系统上，以支持SSI堆栈的更高层？

虽然这似乎与分散的方法相悖，但互联网巨头的用户数据库表明，现代网络就绪的数据库技术可以实现DID登记处所需的稳健性、全球规模和地理分散性。一些人甚至提出，像Facebook这样的大规模社交网络数据库，可以成为快速采用DID的基础--以广泛的覆盖面、经证实的易用性和现有的采用为理由。然而，这样的数据库既不是自助服务，也不是抗审查的。对这些数据库的信任植根于集中的管理员，他们的利益可能与他们所识别的个人的利益不一致。当第三方对每一次登录或互动进行调解时，隐私是值得怀疑的。无论运行这些数据库的组织是政府、私营企业，甚至是慈善机构，情况都是如此。这种集中化破坏了SSI（也是互联网）最重要的设计目标之一：消除单点控制和故障。由于这个原因，大多数SSI的从业者不把传统的数据库作为第1层的一个可行的实施途径。

正如本书开头所述，SSI的诞生是因为区块链技术为实现去中心化的公钥基础设施（DPKI）引入了一个令人兴奋的新选择，因此，很自然地，多种形式的区块链已经成为第一层的首选。

除了众所周知的支持加密货币的公共区块链（如比特币和以太坊），这个技术家族还包括许可账本（如Hyperledger Indy）、分布式有向无环图（如IOTA），以及分布式哈希表（如IPFS）。区块链已经成为整个家族的一个总括性术语，尽管专家们对具体如何应用这些定义有争议。

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

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

考虑到丰富的可能性，我们预计在未来几年内会开发出更多基于对等协议的第一层功能的解决方案，所有这些都会增加SSI堆栈的这个基础层的整体实力。

4 of 7

第2层：安全通信和接口

协议设计

使用身份枢纽（加密的数据库）的面向数据的界面设计。

使用代理的面向消息的界面设计。

使用钱包Dapps进行面向API的界面设计。

界面设计

使用DIDComm的基于消息的协议设计。

使用TLS的基于网络的协议设计。

协议设计和界面设计

如果第一层是关于建立去中心化的信任根--无论是可公开验证的还是点对点的--那么第二层是关于在依赖这些信任根的对等体之间建立可信的通信。这是我们在第二章中介绍的数字代理、钱包和加密数据存储的所在层，也是它们的安全DID-to-DID连接的所在层。

当然，协议是互联网本身的核心--TCP/IP协议栈使互联网成为可能，而HTTP和HTTPS协议则使网络成为可能。对于SSI来说，协议设计是至关重要的，因为它定义了代理、钱包和枢纽的通信规则。

在SSI社区，有两种主要的协议设计架构正在被追求：

基于网络的协议设计遵循W3C经典的 "万维网架构 "文件中详述的相同的基本HTTP协议模式。这种方法对HTTPS协议中使用的传输层安全（TLS）标准有特殊的依赖性。
基于消息的协议设计使用DIDComm协议进行代理之间的点对点通信--这种架构方法更类似于电子邮件

从架构的角度来看，界面设计是关于SSI基础设施如何被那些想要为个人和机构解决现实世界问题的开发者提供程序化使用。这里的方法在一定程度上取决于协议设计。对于基于网络的客户/服务器协议，Swagger风格的API接口是一个自然的补充；对于DIDComm，点对点协议是一个更自然的模型。

SSI解决方案倾向于强调对界面问题的这三个答案中的一个：

面向API的界面设计倾向于使用带有API的分散式网络或移动钱包分散式应用（Dapps）。
面向数据的界面设计使用加密的数据存储来发现、共享和管理对身份数据的访问。
面向消息的界面设计使用数字代理（基于边缘或基于云），为他们共享的消息和互动提供路由。

5 of 7

第3层：凭证

鉴于我们在第1层和第2层描述的所有能力，第3层的互操作性归结为两个简单的问题：

双方将交换什么格式的可验证凭证？
双方将使用什么协议来交换？

凭证交换协议

JSON网络令牌

（JWT）格式

Blockcerts格式

W3C可验证凭证格式

Server

可验证凭证的信任三角，是所有凭证交换（物理或数字）的核心

第3层：凭证

如果说第1层和第2层是建立加密信任--机器之间的信任，那么第3层和第4层就是人类信任进入的地方。具体来说，第3层是第2章中介绍的可验证凭证信任三角形的所在地，如右图所示。

鉴于我们在第1层和第2层所描述的所有能力，第3层的互操作性涉及两个简单的问题。

第3层的互操作性归结为两个简单的问题。

各方将交换什么格式的可验证凭证？
各方将使用什么协议来交换它？

三种主要的凭证格式。

JSON网络令牌（JWT）
Blockcerts
W3C可验证凭证

对凭证格式的一种做法是使用成熟的JWT规范。JWT被设计为认证和授权授予的载体；它们被广泛用于OAuth、Open ID Connect和其他现代网络登录技术。JWTs在各种编程语言中都有很好的支持。

JWT工具的一个挑战是，它没有为解释证书中理想的丰富元数据提供帮助。JWT库可以确认大学成绩单是有签名的，但它不知道大学成绩单是什么，也不知道如何解释它。使用JWT来验证凭证的另一个缺点是，它暴露了签名文件中的一切。没有选择性披露的选项--凭证持有人能够只披露凭证上的某些要求，或证明有关这些要求的事实而不披露要求的价值（例如证明 "我已超过21岁 "而不披露我的出生日期）。

Blockcerts是一个开源的建议标准，用于机器友好的凭证和允许这些凭证被验证的机制。Blockcerts是由Learning Machine设计并倡导的。Blockcerts是经过数字签名的JSON文件，对描述凭证持有人的属性进行编码。它们被发放到一个必须由持有人控制的支付地址，而支付地址被嵌入到签名的JSON中。然后，持有人可以通过证明他们控制着支付地址的私钥来证明该凭证属于他们。

验证一个blockcert可以证明一个证书的以下内容：

它自发行以来没有被修改过。
它是由正确的发行者签署的。
它没有被撤销。

可验证凭证是SSI基础设施的核心，因此有自己的章节（第7章）。为了我们在本章的目的，我们可以总结一下，可验证凭证数据模型是一个抽象的数据模型，它使用关联数据的JavaScript对象符号（JSON-LD-另一个W3C标准，http:// www.w3.org/TR/json-ld）来描述可以有不同模式和数字签名格式的凭证。W3C可验证凭证的使用有两种一般的风格：一种是专注于简单的凭证共享，一种是使用专门的加密签名来促进零知识证明。

无论可验证凭证的格式如何，互操作性仍然取决于该凭证是如何交换的。这涉及到任何数量的复杂协议问题。比如说。

潜在的验证者应该主动联系持有者，还是应该在持有者试图访问受保护的资源时等待挑战他们？
验证者核查员如何询问可能在不同凭证中的声明？
验证者核查员能否在其证明请求中添加过滤器，例如接受在特定日期之前或之后签发的凭证？
验证者核查员是否可以联系持有人以外的一方来获取凭证数据？

这就是第3层对第2层有直接依赖的地方。例如，如果你认为凭证主要是惰性数据，并认为分发身份数据的最佳方式是通过枢纽，那么交换该数据的自然方式可能是调用网络API并要求将数据提供给你。另一方面，如果你更强调去中介化和隐私，并且你希望凭证数据的证明在特定连接的背景下动态生成，那么更自然的答案是使用代理和DIDComm的点对点凭证交换协议。

6 of 7

第4层：治理框架

完整的ToIP栈是一个 "双栈"，左边代表治理层，右边代表技术层。

直接治理框架如何建立在可验证凭证之上

第4层不仅仅是堆栈的顶部；它也是重点几乎完全从机器和技术转移到人类和政策的地方。当我们在第二章介绍治理框架时，我们使用了图5.6所示的图表，因为它显示了治理框架是如何直接建立在可验证凭证之上的。

治理框架使核查人员能够回答一组完全不同但同样相关的关于可验证可核查证书的问题。比如说：

我怎么知道这个驾驶执照是由一个真正的政府机构颁发的？
我怎么知道这张信用卡上的索赔来自于真正的银行或信用社？
联盟？
我怎么知道这个文凭是由加拿大大学颁发的？
我如何发现奥地利的高中所颁发的证书有哪些类型？
奥地利的高中颁发什么类型的证书？
签发此抵押贷款证书的巴西贷款机构是否需要KYC？
我可以依靠日本健康保险凭证中基于出生日期的证明吗？

完整的ToIP栈是一个 "双栈"，左边代表治理层，右边代表技术层。后续章节我们会介绍更多细节。

尽管治理是SSI宇宙中不同的信任网络和生态系统可能差异最大的地方，但ToIP栈的承诺是他们可以使用一个可互操作的元模型来定义这些治理框架。这可以使人类和数字代理更容易地在不同的信任社区中做出过渡性的信任决定。

1 of 7