5.3.2 接口设计方案
从架构的角度来看，接口设计能够让开发人员使用 SSI 基础设施进行编程，为个人和机构解决现实世界的问题，接口设计在一定程度上取决于协议设计。对于基于网站的客户机 /服务器协议，Swagger 的 API 是自然的模式；而对于 DIDComm，对等协议是一个更自然的模式。然而，两种底层协议都可以与任何一种接口配对，所以这个问题在某种程度上是正交的。
SSI 解决方案倾向于强调接口问题的以下 3 个答案之一。
（1） 面向 API 的接口设计倾向于使用分布式的网站或分布式应用程序（DApp）与 API。
（2）面向数据的接口设计使用加密的数据存储来发现、共享和管理对身份数据的访问。
（3）面向消息的接口设计使用数字代理（基于边缘或基于云），为它们共享的交互提供路由。
这些答案并不相互排斥；所有方法都有重叠，只是侧重点不同。
1. 用钱包 DApp 实现面向 API 的接口设计
基于 API 的接口设计方法源于这样一种理念，即 SSI 特性最好通过分布式网站和移动应用程序，以及互补的服务器端组件上相关 Web 2.0 或 Web 3.0 的 API 来公开。在这里，个人典型的 SSI 移动应用程序是移动钱包，它保存所有加密材料，并提供简单的 UX，用于请求和提供基于凭证的身份证明。这个移动钱包还直接或间接地与区块链对接以验证数据。
应用程序 Blockcerts 和 uPort 就是这种模式的示例。这些应用程序分别与学习机器（Learning Machine）的服务器端发布系统或 uPort 的基于以太坊的后端对接。程序员编写自己的应用程序或自动化程序来调用这些后端 API 并使用身份生态系统。因为这种方法在概念上简单明了，所以学习曲线并不陡峭，便于采用。
此模式适用于 SSI 用例，在这种用例中，个人希望向机构证明事情，因为个人携带移动设备，而机构使用 API 操作服务器。然而，当个人是证据的接收者而不是给予者，且当身份所有者是物联网设备或机构而不是人时，这种模式与整体模式存在一些阻抗。例如，物联网设备如何持有移动钱包并控制 DApp ？也许将来我们会看到这种模式的巧妙扩展。
2. 用身份交换中心（加密数据保管库）实现面向数据的接口设计
Digital Bazaar、Microsoft、分布式身份基金会和 W3C 的凭证社区工作组（CCG）中的其他各参与者都支持以数据为中心的身份观点。在这种范例中，使用 SSI 基础结构的参与者的主要任务是发现、共享和管理对身份数据的访问。在这种观点中，管理层的重要部分是交换中心（或者，用 W3C 的说法就是加密的数据保管库），这是一个基于云的交换中心，网络 API 通过它访问身份数据。交换中心是由身份控制器配置和控制的服务。对个人来说，它通常被作为软件即服务（SaaS）订阅和出售，提供一种个人 API。机构或设备也可以使用交换中心。重要的是，交换中心不一定能直接代表特定的身份控制器，它可以是独立的服务，代表任意数量的身份控制器管理数据，由每个单独的控制器指示。图 5.2 说明了交换中心在 DIF 设想的 SSI 生态系统中扮演的角色。
尽管交换中心在理论上可以按照计划或触发器执行代码，但大多数设计文档都将交换中心作为外部客户端的被动响应器。大多数示例都假设它们总是在线，以提供一个稳定的交互门户，并且表现得像一个专门的网络服务器。因此，它们最初被设想为面向 HTTP 和表现层状态转换（REST）式的，而其服务端点是在 DID 文档中定义的。然而，随着 DIDComm的发展，一些交换中心 API 已经被重新设计为基于消息的，并且能够使用蓝牙、近场通信（NFC）、消息队列或 HTTP 以外的其他传输机制。尽管如此，交换中心设计的架构核心仍然根植于数据共享。
交换中心的安全性是通过使用 DID 文档中声明的密钥对消息进行加密来提供的。早期对加密方法的讨论集中在 JSON Web 令牌格式上，它是 JavaScript 对象签名和加密堆栈的一部分，但具体内容仍在开发中。截至 2021 年年初，DIF 的安全数据存储工作组正忙于统一各方工作，以指定可互操作的身份中心和加密数据保管库。
对于希望向消费者和企业提供托管服务的公司来说，交换中心模式很有吸引力。对那些想与消费者签订合同，并从他们的数据中提取价值的机构来说，它也很方便。有利的一面是，针对交换中心的编程对开发人员来说可能非常容易；不利的一面是，目前还不清楚消费者是否愿意采用云中的服务来管理他们的身份。另外，隐私、安全和托管提供商的监管问题也需要探讨。这是一个特别需要市场验证的领域。
3. 用代理实现面向消息的接口设计
Hyperledger Aries 项目和 Sovrin 社区支持一种 SSI 接口范例，它将重点放在活跃代理及其共享的消息和交互上。代理是身份的直接代表，而不是像交换中心一样是间接或外部的代表。与代理交互时，应尽可能直接与代理所代表标识的实体交互。
正如第 2 章介绍的并将在第 9 章深入探讨的，SSI 数字代理可以在任何位置托管，如移动设备、物联网设备、笔记本电脑、服务器或云中的任何位置。代理生态系统的架构图没有将区块链放在交换中心，通常没有像“客户”、API 之类的词。第 2 层 Hyper Ledger Aries 生态系统的范例如图 5.3 所示，心智模型可能是最佳的可视化范例。
这是一个松散的对等代理网格，其中一些代理在第 1 层充当 DID 验证器的节点。
连接不断形成，新的代理节点不断出现。每个连接都需要为每一方提供一个私有、成对的对等 DID。正如本章前面所解释的，这些 DID 及其 DID 文档不写入任何区块链，而是存储在每个代理的钱包中。整个网格是流动的、完全分散的；节点之间的连接是直接的，而无须通过任何中间机构进行过滤。
节点网格是可以横向扩展的，其表现为节点交互和存储数据的集体能力的函数。因此，它的规模和执行方式与互联网相同。绝大多数的协议交换和能产生商业或社会价值的、有意义的交互都直接在代理节点之间发生。一旦通过交换 DID 和 DID 文档形成了对等 DID 连接，所产生的通道（图 5.3 中的虚线和实线）就可以用于各自代理所需要颁发凭证、呈现 / 证明凭证、交换数据、人与人之间的安全消息传递等。
图 5.3 中的圆形代理节点中混杂着几个五边形。这些是验证器节点，将公共区块链服务作为实用工具提供给生态系统。随着区块链的更新，它们彼此保持联系，以保持一致性。任何代理节点都可以接触区块链来测试社区的真实性（例如，检查 DID 文档中公钥的当前
值）。它们还可以写入区块链（例如，创建一个模式，并根据该模式发布凭证）。因为大多数DID 和 DID 文档在这个生态系统中是不公开的，所以代理节点之间的大部分流量不涉及区块链，从而避免了可扩展性、隐私和成本问题。然而，区块链对于建立公共可信根仍然非常有用，如某些机构的 DID 和公钥，这些机构借此发布（和撤销）广泛获取信任的凭证。
这种架构的接口是分布的 n 方协议。这是有状态交互序列的解决方案，代表了应用程序所解决的业务问题（“有状态交互”是 REST 的核心概念，REST 意为表现层状态转换，是一种架构风格）。因为代理并不像服务器那样稳定连接，而且数据共享只是代理的关注点之一，所以协议以加密的 JSON 消息的形式展开，而不是以被调用的 API 的形式展开（尽管可以调用底层 API 来触发特定的消息）。
为了支持这些协议，开发人员只需通过目标代理群体支持的任何一组传输生成和使用JSON。对于许多流行的交互模式，具体协议正处于标准化和实现的不同阶段，包括我们将在下一节中讨论的可验证凭证交换协议。
总之，面向应用的架构（AOA）旨在模拟现实世界中交互的多样性和灵活性，同时仍然提供执行交易所必需的安全性、隐私性和信任保证，如果不能提供这些，则需要人工直接干预，成本高得多，速度也慢得多。AOA 模型不利的一面是侧重于松散协调的参与者，其行为受约束，因此比其他方法更复杂，对网络效应更敏感，并且更难构建和调试。同时，它也具有突发性，更难有把握地描述其特征。因此，只有时间才能证明 AOA 能否在市场上取得成功。
5.4 第3层：凭证
如果第 1 层和第 2 层是机器之间建立加密信任的位置，那么在第 3 层和第 4 层，人类信任加入进来。具体地说，第 3 层是第 2 章中介绍的可验证凭证信任三角的位置。
在这个信任三角中，可以回答以下问题。
（1）要求我提供电话号码的那一方真的是银行吗？
（2）以数字方式签署这份合同的人真的是 X 公司的员工吗？
（3）申请这份工作的人真的有 Y 学位吗？
（4）我想买的那个产品的卖家真的在 Z 国吗？
（5）想买我车的人持有有效护照吗？
（6）我插在墙上插座上的设备真的得到了保险公司的批准吗？
（7）这个袋子里的咖啡真的是在尼加拉瓜以可持续方式种植的吗？
当然，无论是对我们的个人身份、商业身份、政府 / 公民身份，还是社会身份而言，像这样的问题将无穷无尽，涵盖了我们作为人类做出信任决策所需要知道的一切。第 3 层的目标是支持互操作的可验证凭证，这些凭证可以在所有这些身份中使用，从任何发证方、持证方到验证方。
考虑到我们在第 1 层和第 2 层描述的所有身份，第 3 层的互操作性可以归结为两个简单的问题。
（1）各方将交换何种格式的可验证凭证？
（2）各方将使用什么协议来交换它？
这些问题的答案绝不是单一的。SSI 社区在这些答案上有很大的分歧，这意味着第 3 层有可能不具备互操作性。
在本节中，我们将深入讨论不同答案的细节，首先涉及凭证格式，即凭证在线路上和磁盘上是什么样子，然后介绍用于交换凭证的协议。我们介绍如下 3 种主要的凭证格式。
（1） JSON Web 令牌（JWT）。
（2）区块凭证（Blockcert）。
（3） W3C 可验证凭证。
5.4.1 JSON Web令牌（JWT）格式
凭证格式使用成熟的 JWT 规范（RFC 7519）。很多 JWT 被设计为身份验证和授权与授予的载体；它们被广泛应用于 OAuth、Open ID Connect 和其他现代网站登录技术中。各种编程语言都能很好地支持 JWT。
JWT 工具所面临的挑战之一是，它无法帮助解释凭证中所需的丰富元数据。JWT 库可以确认一份大学成绩单已经签署，但它不知道什么是大学成绩单，也不知道如何解释它。因此，凭证的 JWT 解决方案必须添加额外的语义处理层，或者必须将所有这些工作交给专属机构、不可互操作的软件或人类来判断。
使用 JWT 作为可验证凭证的另一个缺点是，它会显示已签署文档中的所有内容，而没有选择性披露的选项。所谓选择性披露，是指凭证持证方只能披露凭证上的某些声明，或者证明关于这些声明的事实，而不披露声明的具体值（例如，证明“我超过 21 岁”，而不必披
露我的出生日期）。
注：“选择性披露”一词在安全和金融领域都有被使用。在隐私社区中，它具有本节所讨论的正面意义。而在金融社区，它有负面的含义：公开交易的公司向一个人或有限的一群人或投资者披露重大信息，而不是同时向所有投资者披露信息。
JWT 最初被认为是短期的令牌，用于在创建后立即进行身份验证或授权。它也可以作为长期的凭证，但是没有任何预定义的凭证撤销机制，比如，要想在 JWT 驾驶执照签发几个月后测试其有效性就不太容易，但可以构建这样的撤销机制，例如，可以使用撤销列表，而
目前还没有这方面的标准，因此也没有工具来支持它。
5.4.2 区块凭证（Blockcert）格式
区块凭证是一种开源代码标准，支持凭证在机器上的验证。它可以使用多个区块链作为凭证的锚。区块凭证是 Learning Machine 设计并支持的。
区块凭证是经过数字签名的 JSON 文档，对描述凭证持证方的属性进行编码。它们被发布到一个必须由持证方控制的支付地址，该支付地址嵌入已签署的 JSON 中。然后，持证方可以通过证明他们控制了支付地址的私钥的方式来证明凭证是属于他们的。为了让区块凭证可以使用 DID，需对区块凭证进行调整，这方面的工作还在进行，但没有公布工作进程。
区块凭证通常是批量发行的。每个区块凭证都被散列化，然后将批处理中所有凭证的散列组合到梅克尔树（Merkle tree）中，并将批处理的根散列记录在区块链上，如图 5.4 所示。梅克尔树在第 6 章中将有更详细的解释。
定义：梅克尔树是一种数据结构，它保存数据的散列、子散列和父散列等。这些散列可以有效地证明数据没有被修改。
验证区块凭证可以证明凭证具有以下特性。
（1）自发行以来没有被修改过。
（2）它是由正确的发证方签署的。
（3）它还没有被撤销。
验证区块凭证涉及对梅克尔证明的评估，这意味着凭证的散列映射到散列链上，该散列链是以存储在账本上的散列结束的。存储在账本上的散列必须是发行方在统一资源标识符（URI）处记录的交易（这意味着由发行方声明的密钥进行数字签名），该统一资源标识符也被嵌入证书中。撤销是通过在另一个存储撤销列表的 URI 上调用发行方的方式来进行测试的（这是一种基于智能契约的撤销功能，可以提高隐私性，但尚未投入开发）。
5.4.3 W3C可验证凭证格式
为可验证凭证的互操作性建立全球标准是 W3C 首先组建可验证声明工作组，然后成立凭证社区小组的主要原因之一。孵化的结果是在 2017 年成立了可验证声明工作组，最终于2019 年 11 月发布了可验证凭证数据模型 1.0，并将其作为 W3C 的完整规范（官方标准）。
可验证凭证是 SSI 基础结构的核心，因此我们将专门用一章（第 7 章）对其进行讨论。从本章我们可以总结出，可验证凭证数据模型是一种抽象数据模型，它使用链接数据的 JavaScript 对象表示法（JSON-LD，是另一个 W3C 标准）来描述具有不同模式和数字签名格式的证书。人们设想了 W3C 可验证凭证使用的两种通用风格：一种侧重于简单的证书共享，另一种使用专门的加密签名来促进零知识证明的应用。
在由 uPort、Digital Bazaar、微软和其他公司倡导的简单凭证共享模式中，凭证包含持证方的 DID（例如，颁发签发对象）。当凭证被出示时，持证方将显示整个凭证，包括这个DID。然后，持证方可以证明凭证属于他们，因为他们拥有控制该 DID 的加密密钥。简单凭证共享模式的一个挑战是，它本质上是不可否认的。一旦共享，凭证可以在没有持证方许可的情况下向任何当事人重新共享。或许立法会澄清如何管理这种再分享的许可。
另一个挑战是，完整地显示凭证提供了一种极其简单但强大的方法，可以在与之共享证书的所有验证方中关联持证方。可验证凭证数据模型规范指出了这种方法存在的隐私风险。简单凭证共享模式的倡导者指出，这些隐私问题通常不适用于企业或企业资产（如物联网设备）的凭证。虽然这是事实，但隐私工程师非常担心，如果简单的凭证模型扩展到人，那么它将成为历史上最强的关联技术，因此，可以说这是所有 SSI 架构中最激烈的争论之一。
零知识证明（ZKP）模型试图解决这些隐私问题。ZKP 模型最著名的应用实例就是 Hyperledger Indy 项目。微软曾宣布了自己的 ZKP 模型计划，并且也开始研究 JSON-LD-ZKP混合方法，Hyperledger Aries 和 Hyperledger Indy 项目也可能最终共享这种方法。
基于 ZKP 的凭证不会直接提供给验证方。相反，这份 ZKP 凭证只包含验证方需要验证的数据，不多也不少。（关于 ZKP 技术，将在第 6 章做更详细的解释）。此外，每次要求提供证明时都会生成一个唯一的证明，这样证明的可重新共享性可以由持证方加密控制。由于每一次展示的证明都是唯一的，因此避免了使用相同凭证产生的琐碎关联。
例如，假设 Alice 所生活的城市可以向居民提供免费电动汽车充电服务。Alice 可以日复一日、长达数年地向充电站证明她的居住资格，而充电站却无法跟踪 Alice 在城市充电站的轨迹。每一次证明的展现都是不同的，并且没有披露任何相关的信息。
需要注意的是，这种技术并不是在所有情况下都能消除相关性。例如，如果验证方在证明中要求 Alice 公开真实姓名或手机号码，关联她就会变得很容易。然而，如果证明要求高度相关的个人数据，Alice 的代理可以提醒她，这样她就可以做出明智的决定。
ZKP 的凭证也可以采用一种独特的方法来撤销。它们可以使用保护隐私的密码累加器或植根于区块链的梅克尔来证明，而不是撤销列表。（请参阅第 6 章了解更多详细信息）这允许任何验证方实时检查凭证的有效性，而不能以产生关联的方式查找特定的证书散列或标识符。
关于 ZKP 模型的主要争议是其实现的复杂性。ZKP 是密码学的一个先进领域，并不像传统的加密和数字签名技术那样被广泛理解。然而，ZKP 的优势在许多不同的技术领域都得到了认可，因此 ZKP 的应用正在迅速普及。包括 ZCash 和 Monero 在内的许多较新的区
块链都基于 ZKP 技术。下一代以太坊构建了对 ZKP 的支持。Hyperledger Ursa 也构建了对ZKP 的支持，这是一个工业级加密库，它现在是所有超级账本项目的标准。当年对新出现的TCP/IP 的支持一直受到阻碍，直到开发人员可以使用强化库为止，如今 ZKP 也正如此。
5.4.4 凭证交换协议
无论可验证凭证的格式如何，互操作性仍然取决于该凭证的交换方式。这涉及许多复杂的协议问题。
（1）潜在的验证方应该主动与持证方联系，还是应该等到持证方试图访问受保护资源时再提出质疑？
（2）验证方如何要求出示处于不同凭证中的证明？
（3）验证方是否可以在其证明请求中添加筛选器或资格情况，例如，只接受来自特定发证方的证明，或者只接受在特定日期之前或之后签发的凭证？
（4）验证方是否可以联系持证方以外的一方以获取凭证数据？
这就是 Top 堆栈中第 3 层直接依赖第 2 层的原因。例如，如果你认为凭证主要是惰性数据，并且认为分发身份数据的最佳方式是通过交换中心，那么交换数据的直接方式可能是调用网络 API 并要求提供数据。凭证持证方可以将证书留在交换中心并通过一种策略告诉交换
中心在将其提供给任何询问者之前必须满足哪些标准。这是 DIF 身份中心孵化的凭证服务API 所采取的方法中体现的一般范例。
如果你更强调分布式和隐私，并且希望在特定连接的背景中动态生成凭证数据的证明，则可通过代理和 DIDComm 使用对等凭证交换协议。这是 Hyperledger Indy、Hyperledger Aries 和 Sovrin 社区的方法。（在 Aries RFC 0036 ：发行凭证协议 1.0 和 Aries RFC
0037 ：当前协议生产 1.0 中指定协议。这些协议的多个实施项目已经在建设了。）
在撰写本书时，这是架构和协议在理念上分歧最大的一层。标准化工作是积极的，但到目前为止难以达成共识。然而，从“玻璃杯半满”的角度来看，这也是现实世界中“应用最快推动融合”的领域，就像早期的“协议之战”一样，如开放系统互联（OSI）与 TCP/IP
的斗争最终孕育了互联网。DIF 的 Exchange Presentation 规范就是一个令人鼓舞的例子，它描述了验证方要求基于凭证的证明具备哪些条件，而不管使用的是哪种凭证技术。
5.5 第4层：治理框架
第 4 层不仅仅是堆栈的顶部，在这里，该层基本上把重点从机器和技术转移到人和政策。在第 2 章中介绍治理框架时，我们使用了图 5.5 所示的图，因为它展示了治理框架如何直接构建在可验证凭证上。
图 5.5 治理框架是另一个信任三角，这种治理框架解决了可验证凭证的规范和可缩放性问题
治理框架使验证方能够回答关于可验证凭证的一组完全不同但同样相关的问题。
（1）我怎么知道这个驾驶执照是由真正的政府机构颁发的？
（2）我怎么知道这张信用卡上的声明来自真正的银行或信用社？
（3）我怎么知道这张文凭是加拿大大学颁发的？
（4）我如何发现奥地利高中颁发的是什么类型的凭证？
（5）签发此抵押贷款凭证的巴西贷款机构是否需要了解你的客户？
（6）我可以信赖日本健康保险凭证中出生日期的证明吗？
治理框架是许多 SSI 解决方案的核心组成部分，因此我们将用一整章来介绍（见第 11章）。因为它们也是 SSI 堆栈中较新的组件之一，所以还没有创建很多特定于 SSI 的治理框架。这也与联合身份系统（trust frameworks）设计的信任框架形成鲜明对比。
然而，SSI 治理框架的早期工作已经使许多 SSI 架构师相信这些框架对于 SSI 的广泛应用至关重要，正所谓“玉瓷之石，金刚试之”。换句话说，它们是 SSI 堆栈的技术实现与 SSI 解决方案的实际业务、法律和社会需求之间的桥梁。此外，这些架构师意识到治
理框架适用于 SSI 堆栈的所有 4 个层级。加拿大不列颠哥伦比亚省新兴数字倡议执行主任 John Jordan 将这种技术和治理的结合命名为 Trust over IP（ToIP）堆栈。完整的 ToIP堆栈如第 2 章图 2.14 所示，是一个“双堆栈”，图 2.14 中左侧表示治理层，右侧表示技术层。
在撰写本书期间，ToIP 获得了足够的支持，以至于 Linux 基金会专门启动了一个名为ToIP 基金会的新项目，以此来作为超级账本和分布式身份基金会的姊妹项目。该项目从2020 年 5 月的 27 个创始成员发展到 2020 年年底的 140 多个成员，本项目现在有 7 个工作组积极致力于全面定义、强化和推广 ToIP 堆栈，并将其作为分布式数字信任基础设施的模型。
尽管治理是 SSI 领域中不同信任网络和生态系统之间的最显著差异，但 ToIP 堆栈承诺，它们可以使用可互操作的元模型来定义这些治理框架。这可以使人类和数字代理更容易地横跨不同的信任社区做出可传递的信任决策，例如，本节开始时列出的许多问题。
在撰写本书时，为了在所有 4 个层级上生成符合 ToIP 的治理框架，世界各地的各种权限治理组件正在积极地开展工作。第 11 章将更详细地讨论这些问题。
5.6趋同潜力
SSI 领域还很年轻，市场上不断出现许多新的架构。在这一章中，我们试图从大局概述截至本书撰写时的市场状况。我们也认识到了现实情况—SSI 在很多领域仍存在诸多分歧。
在 4 个层级上都是如此：第 1 层是不同的 DID 方法，第 2 层是不同的协议和接口，第 3层是不同的凭证格式和协议，第 4 层是不同的治理和数字信托生态系统方法。
然而，在每一个层级上，也存在着趋同的可能性。好消息是，这正是市场力量所希望的。随着 20 世纪初汽车行业的兴起，市场力量推动了四轮和内燃机行业的标准化。随着互联网的出现，同样驱使我们对 TCP/IP 堆栈进行标准化。网络驱使我们对基于 HTTP 的浏览器和网络服务器进行标准化。
我们希望，同样的市场力量将推动 SSI 的趋同化，使其也能被普遍采用。然而，可能还有更多的惊喜等待着我们。很可能在未来很长的一段时间内，数字身份架构仍是创新的沃土。
在第 6 章中，我们将提供一些基础的加密知识，这些知识将有助于你理解第 2 部分中的部分章节，特别是 VC 和 DID。如果你已经对密码学有了深刻的理解，那么你可以跳过第 6章，或者只是大致浏览一下，了解这些密码技术是如何在 SSI 中应用的。
