第3章 用示例场景演示SSI工作原理
Daniel Hardman 是 Evernym 的前首席架构师和首席信息安全官，现在是 SICPA 的首席生态系统工程师，在 SSI 被称为自主管理身份之前，他就一直在设计 SSI 基础结构。他在市场中亲身体会了基本 SSI 交互模式的多个实例。
在第 2 章中，我们谈到了 SSI 的核心组成部分。在本章中，我们将通过 7 个由简单到复杂的示例场景，向你展示如何将这些构件组合在一起来实施自主管理身份。我们的目标是展示 SSI 模式的工作原理与中心化或联邦化身份管理模式的不同。
我们选择的场景如下。
（1） Alice 和 Bob 在会议上见面后建立了联系。
（2） Bob 通过 Alice 的博客认识她。
（3） Bob 登录 Alice 的博客并留言。
（4） Alice 和 Bob 通过在线交友网站结识。
（5） Alice 申请银行账户。
（6） Alice 买车。
（7） Alice 把车卖给 Bob。
我们的示例场景使用了 Alice 和 Bob 这两个角色，这两位已经成为密码学和网络安全领域的标志性角色，以至于维基百科上有一整篇关于他们的文章。每个场景都阐述了 SSI 应用的基本模式，在本书第 4 章探讨的行业特定 SSI 场景中，这种模式将反复出现。
3.1 SSI场景图的简单表示法
在本章中，我们将使用图 3.1 所示的简单图示符号。作为消费者和企业，我们每天会遇到无数的信任问题，而用这 11 个符号就可以说明我们是如何运用 SSI 数字凭证概念解决这些问题的。这些符号大多不言自明，但这里我还是解释一下。
（1）人—持有 SSI 的个人（如 Alice 和 Bob）。
（2）组织—持有 SSI 的组织或团体。
（3）物—具有 SSI 的物理、逻辑或自然对象（如物联网上的设备）
（4）边缘代理和钱包—个人或组织用于存储、管理和共享其 SSI 数字凭证的设备和软件（请参阅第 2 章和第 9 章）。
（5）云代理和钱包—与边缘代理相同，但在云端操作。
（6） QR 码（快速响应码）—即二维码，可以被智能手机、平板电脑或其他计算设备上的摄像头读取以启动交互动作。
（7）初始—在任何两个 SSI 持有者（如 Alice 和 Bob）之间建立数字身份关系的第一步。
（8）连接—两个 SSI 持有者之间经同意建立的关系，其代理相互交换加密密钥，以形成安全的、私有的加密通信通道。
（9）凭证—可验证的数字身份证书（见第 2 章和第 7 章）。
（10）证明—证书中具体信息的证明，须有数字签名且可加密验证。
（11）验证—代理成功验证“证明”而得出的结果。
在所有这些场景中，我们还使用了第 2 章（如图 3.2 所示）中介绍的可验证凭证信任三角中的 3 个核心角色—发证方、持证方和验证方。
3.2 场景1：Bob和Alice在会议上见面后建立了联系
所有形式的数字身份都存在于某种关系背景中。在典型的企业身份和访问管理场景中，其关系可能是员工和公司之间的关系，也可能是消费者和网站之间的关系；而在物联网场景中，则可能是物联网设备与其制造商或所有者之间的关系。
所有这些场景都是典型的客户端 - 服务器关系，其中，身份持有者使用浏览器等客户端软件与企业控制的服务器建立身份（注册）并进行身份验证（登录）。这种典型的基于账户的身份模式使用的是第 2 章所述的中心化或联邦化身份管理模式。
而 SSI 模式则更为广泛，它基于任意两个实体之间的“点对点”关系，而客户端 - 服务器关系只是其中的一种。为了强调这一点，我们即将介绍的第一个场景是商业中最常见的互动之一：Alice 和 Bob 在会议上见面并交换名片。
（1） Alice 和 Bob 都不是对方的“客户”，他们只是同行。
（2） Alice 和 Bob 都没有运行“服务器”。
（3）他们都没有与对方建立“账户”—相反，他们只是在同行之间建立一种联系。
在数字时代之前，这种简单的点对点交流如图 3.3 所示。
然而，在当今的商务会议上，信息连接往往是数字化的，比如使用手机和像 LinkedIn这样的商务网络，所以现在的方式看起来更像图 3.4 展示的。
这种数字化的方式不仅节约了纸张，还把联系信息直接放在最有用的地方——手机。更妙的是，如果该连接是通过 LinkedIn 这样的商业网络建立的，那么即使 Alice 和 Bob 换了工作、电子邮件地址或电话号码，这种连接也会持续存在。然而，与 LinkedIn 分享这些信息是有代价的，对于我们很多人来说，这不是问题，因为由暴露隐私带来的不适感被便利性抵消了。但对那些职业需要保密或对安全敏感的人来说，使用 LinkedIn、Facebook 或 Twitter这类公共社交网络的方式并不可取。
如果 Alice 和 Bob 有一种简单、快速的方式来建立他们自己的连接，而且这个连接是直接的、点对点的，且不需要任何中介，那会怎么样呢？如果这个连接创建了一个只有 Alice和 Bob 可以使用的安全私用通道，又会如何？如果这种联系能永远持续下去，或者直到
Alice 或 Bob（或两人都）决定不再需要它时才终止，那要怎么办呢？
利用在第 2 章中介绍的 SSI 基本构成元素，我们可以采用完全分布式的方式构建这种连接，而不需要依赖任何中间方。实际的实现形式取决于 Alice 和 Bob 的智能手机及数字代理的具体能力。但他们可以选择一种流行的方式——扫描二维码，使用过电子登机牌的人对此都很熟悉（如图 3.5 所示）。
为了方便联系，有些人在名片上印上了二维码。但这些二维码通常会把你带到像LinkedIn 这样的集中式服务提供商那里，在服务提供商的专用网络上建立连接。
使用 SSI，你可以在无须任何中间服务提供商或专用网络的情况下创建一个连接。Alice和 Bob 通过加密方式把他们手机上的钱包和数字代理直接连接起来，所以该连接对他们两个人来说是完全私用的。不管是 Alice 扫描 Bob 的二维码，还是 Bob 扫描 Alice 的二维码，都无关紧要。无论以哪种方式，一旦 Alice 和 Bob 二人都批准了，就会在他们的两个数字代理之间创建一个直接的、私用的“点对点”SSI 连接，如图 3.6 所示。
使用 SSI 建立联系，无须中介，这对人际沟通与信任的未来有着深远影响。当不再需要中介时，该中介强加的所有条款、条件和限制都将消失。这两个对等方可以自由地构建关系、建立信任及使用最适合的方式进行数据交换，所有这些都是早期互联网想要实现的目
标。所以在很多方面，SSI 只是在帮助我们重新建立互联网本身最初的去中心化愿景。
当然，图 3.6 过于简化了。它没有显示出正在使用的具体硬件和网络，也没有显示正在交换的 DID 和 DID 文档。但从概念上讲，它准确地描绘了 Alice 和 Bob 创建了彼此之间的联系后的情况。
背后的原理是什么？
对于技术型读者来说，图 3.7 所示进一步细化了这个场景。如果你不需要了解技术细节，请跳过此部分。
图 3.7 更详细地展现了 Alice 和 Bob 之间是如何形成连接的，显示了边缘代理（在 Alice和 Bob 各自的智能手机上）与位于 Alice 和 Bob 各自的云代理之间的通信。
让我们解释一下 Alice 和 Bob 是如何各自配置图 3.7 中所示的边缘代理 / 钱包和云代理的。他们首先下载 SSI 移动钱包 App（或者使用安装在智能手机上的应用程序）。就像浏览器和电子邮件 App 一样，Alice 和 Bob 是否使用相同的移动钱包 App 并不重要，只要他们的App 支持 SSI 互操作性的开放标准即可。
当 Alice 和 Bob 第一次打开各自的移动钱包 App 时，他们的边缘代理软件应该会提示他们设置云代理。这类似于将你的智能手机设置为使用云备份服务。不同的 App 将与不同的云代理服务提供商（称为 SSI 代理）合作，后者提供托管云代理的服务。这个过程不到一分钟，并且只需要做一次（一旦你的边缘代理与云代理配对，它将会持续工作，除非你决定中断连接并与其他云代理配对）。
一旦 Alice 和 Bob 设置了他们的移动钱包、边缘代理和云代理，那么这个场景就将按下面的步骤进行（假设是 Alice 生成一个二维码让 Bob 扫描，反过来由 Bob 生成二维码，场景也是一样的）。
（1） Alice 生成一个二维码
Alice 在她的移动钱包 App（边缘代理）中单击菜单选项，使其生成一个新连接的二维码，名为“连接邀请”。该请求包括关于 Bob 的代理如何通过加密通道可靠地联系她的信息。这个二维码中的数据并不需要保密，不需要强有力的安全保障，加密通道将在后面的流程中添加这类保障。
在生成二维码之前，Alice 的边缘代理生成一个用于确保安全的“随机数”并将其发送给 Alice 的云代理，通知它将要收到一条与该随机数相关的消息。Alice 的二维码中包含了这个随机数，因而该二维码对 Bob 是唯一的。
（2） Bob 用移动钱包 App 扫描二维码
一旦 Bob 的边缘代理识别出这是一个新的连接邀请，它就指示钱包生成以下内容。
① 一个唯一的新公钥 / 私钥对。
② 一个基于该公钥 / 私钥对的对等 DID（Peer DID）。这个对等 DID 是一个私用的成对假名标识符，它将用于以一种只有他们两个人知道的隐私保护方式来标识 Bob 与 Alice 的唯一连接。
一旦将密钥对、对等 DID 保存在 Bob 的钱包中，他的边缘代理就会编写一个“连接请求”消息，其中包括一个 DID 文档（每个 DID 附带的元数据文档，参见第 2 章和第 8 章）。这个DID 文档是专门为 Alice 准备的：它包括新的对等 DID、对应的公钥和 Bob 的云代理的网络地址（称为“服务端点”，因为其他代理可以通过服务端点“调用”Bob 的代理来发送消息）。Bob 的边缘代理将他的连接请求消息发送给 Bob 的云代理，并指示其通过 Alice 在其连接邀请中标识的加密通道将消息转发给 Alice 的云代理。
（3） Alice 采取行动
Alice 的云代理接收到 Bob 的消息，并将消息推送给 Alice 的边缘代理，询问 Alice 是否要确认连接。Alice 的边缘代理提示 Alice 确认该连接，Alice 单击“是”后，Alice 的边缘代理将 Bob 的一半连接信息保存在其钱包里。
现在，Alice 的边缘代理做了与 Bob 相同的事情：生成一个唯一新公钥 / 私钥对及一个只为 Bob 所知的对等 DID，并将其保存在钱包中，接着创建了一个连接响应，该连接响应是Bob 连接请求的镜像，其中包含 Alice 自己的对等 DID、公钥和连接服务端点。Alice 的边缘代理可以使用 Bob 的 DID 文档中的公钥加密此消息，以便于只有 Bob 可以读取它。并且可以将其发送到 Bob 为 Alice 指定使用的专用服务端点。最妙的是，Alice 的边缘代理可以使用该消息更新 Bob 最初连接她时用的服务端点和密钥。这样就把来自连接
邀请的不安全信息替换为新的安全信息，以防任何窃听者。
一旦准备就绪，Alice 的边缘代理就将她的连接响应发送给她的云代理，并指示将其转发到 Bob 的代理给予 Alice 的私用服务端点。
（4） Bob 的代理完成连接的最后一步
Bob 的云代理将连接响应转发给 Bob 的边缘代理，后者将描述 Alice 一半对等 DID 连接信息的 DID 文档保存在 Bob 的钱包中。Bob 的边缘代理通知 Bob 双向连接已经完成。现在，Alice 和 Bob 拥有了永久的私用连接，他们可以进行加密安全通信了。对此要注
意以下 5 点。
① 因为该连接是 Alice 和 Bob 双方亲自建立的，所以他们不需要交换可验证凭证就可以信任对方。但这并不意味着将来不需要交换某种类型的凭证，比如当他们要做一个高风险的商业交易，则可能需要交换某种凭证，但是现在他们对彼此足够信任。
② 不需要与公共账本或区块链进行交互。整个过程都用对等 DID 和 DID 文档进行并完全在区块链下生成和交换，这既有利于保护隐私，又有利于保持其可扩展性。一般来说，只有凭证发行人才需要在公共区块链上注册公共 DID，并允许任何人都能够对其进行验证。
③ 该连接是完全私用的，只有 Alice 和 Bob 知晓。除托管云代理和传递加密消息外，中间不涉及任何互联网中介服务提供商。那些云代理托管提供商（代理）只知道双方代理之间存在流量。他们无法“看到”消息内部，也无从知道谁在和谁谈论什么（通过在代理之间采用洋葱路由，可以进一步保护隐私）。
④ 如果 Alice 或 Bob 中的任何一方（或两者都）更改了他们的云代理，那么连接就会随之移动。它们各自的代理只需要向对方发送连接信息的更新，同时提供新代理的私用云代理地址即可。
⑤ 此连接邀请流程在任何地方都可以进行。它不需要预先建立安全通道；受邀的收件人也不需要了解任何关于 SSI、DID 或移动钱包的信息。这也是 SSI 在没有任何中心化组织或网络推动的情况下迅速增长的原因之一。
3.3 场景2：Bob通过Alice的博客认识她
此场景也会在 Alice 和 Bob 之间建立连接，但这次他们不见面，相反，Bob 在 Alice 的博客上发现了她的网站设计业务。Bob 喜欢她的博客内容，并决定要联系 Alice，请她为自己创建网站。
Alice 是一位前沿的网页设计师，她通过 SSI 开启博客，这样她的博客就可以接受想要直接与 Alice 连接的访问者的连接请求。她在自己的博客中添加了一个云代理，并将其连接到自己的边缘代理。因为这是 Alice 的个人博客，这个云代理充当了 Alice 作为个人的另一个代表，这并不意味着她的博客是一个独立的“物”。这说明了 SSI 的一个关键原则：Alice可以在她需要的设备或网络位置上拥有尽可能多的代理，每一个代理都允许 Alice 在特定的背景下表达她的身份并建立新的关系：在这种情况下，她是作为一位网页设计师而在线存在的。
注：如果 Alice 愿意，她可以设置博客让它拥有独立的 SSI，这样访问者就可以直接与博客而不是与 Alice 形成连接。
图 3.8 显示了在此场景中建立的代理和连接过程。数字表示采取行动的顺序。这个场景从 Bob 决定通过 Alice 的博客提出连接请求开始。
（1） Bob 用他的边缘代理扫描二维码获取连接邀请。这个二维码是由 Alice 博客内置安装的 SSI 插件生成的。
（2） Bob 的边缘代理 App 提示他接受连接邀请。当 Bob 单击“是”时，他的边缘代理为该连接请求消息生成密钥对、对等 DID 和 DID 文档，如前文所述，并将其发送给 Bob 的云代理，让其转发给 Alice 的云代理，然后转发给 Alice 的边缘代理。
（3） Alice 接收连接请求并批准它。这个场景的其他部分与前一个场景一样，Alice 的边缘代理生成她的密钥对、对等 DID 和连接响应消息的 DID 文档，然后通过云代理将该消息发送回 Bob 的边缘代理，在那里存储该消息以完成连接。
注意，与场景 1 一样，此场景不需要任何可验证凭证的交换。如果 Alice 愿意接受她的博客读者的连接请求，她的代理就无须再要求任何进一步的身份信息。但这也使 Alice 面临接收滥发连接请求的风险。为了防范这些风险，Alice 的边缘代理可以要求提供 Alice 信任的一个或多个通用可验证凭证的证明。我们将在场景 4 中进一步描述。
背后的原理是什么？
Alice 把她的博客放在 WordPress 上，所以我们假设 WordPress 具备 SSI 插件（在本书写作时，这样的 WordPress 插件正在开发中）。当 Alice 安装这个插件时，会显示设置云代理所需的二维码。Alice 使用手机上的边缘代理 App 扫描这个二维码。然后，她的边缘代理App 会提示她批准为其博客建立云代理。
Alice 单击“是”后，边缘代理向 Alice 的现有云代理发送消息，要求：①提供新的博客云代理；②在博客云代理和 Alice 的边缘代理之间建立连接。完成后，Alice 的现有云代理向Alice 的边缘代理发送连接响应，其中包括网络地址及公钥的对等 DID 和 DID 文档，用于与她的新博客云代理进行加密通信。
现在 Alice 的博客有了一个新功能：能够向任何想要请求与 Alice 建立联系的读者显示唯一的二维码。
注意，Alice 可能需要在 SSI 化在线资源上设置自己的代理，用于处理她的 LinkedIn 页面、Facebook 页面和她设计的网站，甚至包括她电子邮件上的签名。对于任何 SSI 化在线资源来说，过程都是一样的。Alice 还可以把 SSI 化在线资源用于她想要为之建立代理的任何离线应用，比如她的名片或者她挂在当地画廊中某幅画作上的标牌。
如果 Alice 希望她的博客有自己的一套连接呢？
在我们刚才描述的场景中，我们假设 Alice 希望她的博客充当她的另一个私用代理，但是，如果她想让自己的博客独立存在，比如想让访客可以直接从她的作品集中订购印刷品，那该怎么办呢？在这种情况下，请求连接的访客将直接接收到与 Alice 博客的连接，而这种情况下的 Alice 博客是以“物”的形式参与连接，而非以“人”的形式。Alice 仍然会控制这个“物”的云代理。从法律角度来看，这可能代表她作为艺术家的独资经营权，但“物”的云代理将与代表个体的 Alice 个人代理分开。
在理想情况下，SSI 插件会让博客所有者选择如何配置云代理：代表“人”还是代表“物”。
3.4 场景3：Bob登录Alice的博客并留言
一旦 Bob 与 Alice 建立了连接，Bob 就可以使用该连接随时向 Alice 验证自己的身份。例如，如果 Bob 后来返回到 Alice 的博客并想留下评论，Bob 不需要在 Alice 的博客创建“账户”，他的连接就是账户。所以 Bob 不仅不需要为 Alice 的博客创建新的用户名和密码，还永远不用记住它们，如图 3.9 所示。
无密码登录（或自动身份验证）是 SSI 的主要功能之一。对于任何 SSI 化网站或应用程序，其工作方式都是一样的。图 3.9 显示了其基本顺序。
（1） Alice 的博客生成二维码。就像场景 2 一样，第一步是 Alice 的博客生成一个二维码，供读者在需要认证时扫描（例如，要留下评论或做任何其他需要授权的事情）。这一次，当Bob 扫描二维码时，他的边缘代理识别出 Bob 已经和 Alice 有了联系。因此，Bob 的边缘代理请求 Bob 确认他想要进行身份验证（或者 Bob 告诉他的边缘代理跳过这类确认，他的边缘代理将继续往下进行）。
（2） Bob 的边缘代理生成，签署并发送证明。此证明是用 Bob 的移动钱包中的私钥签署的，仅用于此私用对等 DID 连接。然后边缘代理将证明发送给他的云代理，再转发给 Alice博客的云代理。
（3） Alice 的博客云代理接收并验证该证明。博客云代理使用其与 Bob 私用连接的公钥来验证签名（在连接建立后由 Bob 进行共享，并且在 Bob 的边缘代理更换加密密钥时由Bob 进行更新）。如果签名得到验证，Bob 即可“登录”。
关于身份自动验证的特别强大之处在于，它可以针对特定事物进行调整，要求验证器启用所需的身份验证级别。例如，在博客上留下评论是一种风险相对较低的活动，因此 Bob只要证明他拥有连接的私钥（只有 Bob 知道）就足够了，但 Bob 如果要求信用社进行一笔10 万美元的交易，由信用社生成的二维码可以要求 Bob 出具更有力的证明来证明对方确实是 Bob。
SSI 代理还可以生成其他网络身份验证协议（如 OpenID Connect 和 WebAuthn）所需的身份验证令牌。
