ToIP 发布首个公开审查的技术架构规范
关于ToIP基金会, 我曾经写过一篇介绍文章，不了解的读者可以先看一下。在11月14号，ToIP发布了首个公开审查的技术架构规范。这是什么意思呢？要从ToIP Stack的演进说起。
ToIP Stack的演进
ToIP开发阶段图如下：
可以看出，4个阶段螺旋前进，包括
- 设计原则。首先要对ToIP Stack的总体设计原则达成一致。这个过程涉及ToIP的所有工作小组，在2021年双11的时候，经过ToIP的指导委员会批准，发布了ToIP Stack设计原则1.0 。
- 技术架构。第二阶段是将设计原则应用于ToIP Stack的原始概念，以开发一套完整的分层架构需求。 2022年11月14 日发布了ToIP技术架构规范 V1.0 的第一份公开审查草案。也就是目前的状态。
- 组件规范。这些是完全实现技术架构要求所需的规范。 这些规范中的绝大多数预计来自其他标准组织（例如，W3C DID 1.0、W3C 可验证凭据数据规范 1.1、ISO 移动驾照、DIF DIDComm V2）。 ToIP 基金会只打算在没有其他标准组织做而又必须的地方定义新的组件规范。
- 互操作性测试。实现完全可互操作的 ToIP 应用程序的最后阶段是开发独立于供应商的互操作性配置文件、测试套件和证书框架，它们可以演示满足所有必要的组件规范。
由于很多组件规范都由第三方定义，所以ToIP在这个意义上属于一个协调组织，但是协议本身需要互通，因此ToIP又是必要的。
ToIP 设计原则V1.0
简要列举一下，有兴趣的读者请参考原文 。
第一部分：计算机网络架构原则(“干代码”部分)
- 端到端原则
- 连通性是连通性的自我奖赏(全网互操作性)
- 沙漏模型
- 分权治理(设计的和默认的)
- 密码学可验证
- 机密性(设计的和默认的)
- 密钥在边缘
第二部分：人类网络架构原则(“湿代码”部分)
- 信任是关于人的
- 信任是基于关系的
- 信任是有向的
- 信任是场景相关的
- 信任是有限的
- 信任可以传递
- 信任和技术有互惠的关系
第三部分：总体原则
- 为道德价值而设计
- 为简洁性而设计
- 为永远的变化而设计
参考架构概述
本节来自原文第6节。
设计目标
ToIP Stack的总体目标如下：
- 定义在任何两个或多个端点系统之间建立信任的一般方法
- 不同实现之间的通用互操作性
关于第一个设计目标，要在各方之间建立信任，需要每一方对以下特性建立信心：
- 真实性：通信的接收者是否能够验证它的来源（信息发送者)并没有被篡改？
- 机密性：通信的内容是否受到保护，因此只有授权各方可以访问？
- 隐私：一方对使用共享信息的期望是否会得到另一方的尊重？
请注意，在某些信任关系中，机密性和隐私可能是可选的。 因此，ToIP Stack的设计目标是按列出的顺序实现这三个属性。
关于第二个设计目标，ToIP 参考架构与原始的互联网架构具有相同的全球可扩展性目标。 正如 ToIP Stack的前四个设计原则所总结的那样，这涉及几个相互交织的考虑因素，这些考虑因素相互重叠和加强：
- 端到端原则
- 连通性是连通性的自我奖赏(全网互操作性)
- 沙漏模型
- 分权治理
4层模式
根据这些目标，设计了4层模式，如下表
| 层编号 | 一般名称 | ToIP名称 |
|---|---|---|
| 4 | 应用程序 | 可信应用程序 |
| 3 | 支持协议 | 可信任务 |
| 2 | 跨层协议 | 信任跨层 |
| 1 | 支撑协议 | 信任支撑 |
这四层的设计模式和TCP/IP类似，和沙漏设计模式匹配如下
作为对比，考虑TCP/IP的沙漏设计模式
关键在于沙漏中间最细的部分(跨层)，例如上面的信任跨层或者IP层，有两个设计目标
- 所有底层协议被这层所抽象，上层协议无需知道底层细节
- 能够支持多样化的上层协议
因此，这层需要简洁而不简单：简洁主要是指让上层访问起来接口统一而自身最小; 不简单是指能满足多样的上层生态。
高层系统架构
端点系统，简称端点，用户的计算机和手机是最为直观的例子。中介系统用来帮助端点系统交互，例如邮件服务。支持系统包含用来支持端点系统定义所需要的组件。
三个子系统的交互模式分为三种:
- 端点到端点交互
- 端点和中介交互
- 端点和支持系统交互
端点系统的设计是按4层模式来的，越往上，端点的角色就会被赋予场景相关的确切名称，例如在第3层，与可验证凭据相关的角色，有“发证方”、“持证方”和“验证方”。
ToIP 标识符
端点系统和其分层栈
本节来自原文第7节。
端点系统
端点系统代表受某个实体(party)直接控制的 ToIP 系统。 端点系统的边界由其控制范围划定。 某个实体是指评估、依赖和受益于信任关系的实体。 换句话说，某个实体是系统的任何用户，而不考虑他们在系统中的角色。 这与传统的IAM不同：IAM系统中包含两类用户，一类用户做出信任断言，而依赖方通过这些信任断言做出信任决策。 在 ToIP 系统中，端点系统在第2层（信任跨层）中具有点对点的对称信任关系。
端点系统是自治的，因为根据定义，某个实体的控制边界是整个端点系统。 这意味着其他端点系统、中介系统或支持系统的潜在危害不会直接危害给定端点系统的完整性。 每个端点系统可以很简单也可以很复杂，即它可能有许多进一步划分的功能和/或服务，但是在这个参考架构中，我们应考虑抽象层面的的系统自治。 实施者应该确保端点系统的自治。[REQ A.1]
端点系统的例子包括
- 一个人拥有和控制的手机
- 一个商家所管理的Web服务(自建的或云上的)。
- 一个金融机构所管理的分布式数字服务，包含特定的包含信任功能的在线服务。
- 一个城市所管理的IoT传感器，该传感器可用于污染检测。
为了符合设计原则1（端到端原则），端点系统是ToIP架构需求的终极目标。 与中介或支持系统相比，它们的数量在级别上要大得多。 它们实现了 ToIP 架构中的大部分功能，代表了互操作性和可扩展性的最大挑战。
在端点系统的控制范围内，高层通过接口使用低层的功能。 在ToIP架构中，端点系统中的功能被分解为垂直栈中的层，其中层边界由其相应的接口定义。 在 ToIP 端点系统中，ToIP Stack的高层必须通过定义的接口与低层通信。[REQ A.2]
除了由端点系统控边界内的硬件和软件资源实现的内部层接口外，端点系统还可能依赖位于端点系统控制范围之外但可通过互联网访问的其他支持系统的服务履行其职能。 这种类型的交互需要定义好的协议。
接口和协议之间的区别在于通过协议进行通信的系统是否代表不同的控制边界。 例如，如果所有功能都在同一控制边界之内，则简单地在特定层内通过互联网使用分布式函数（例如使用云计算或 Web 服务执行某些功能）不需要定义协议（注：指ToIP Stack关注的协议）。 但是，如果通信系统处于不同的控制边界，则需要定义协议。 关键在于描述谁控制什么，以便推理信任关系。
L1: 信任支撑层
如果 ToIP 端点系统在其控制范围内包含信任支持功能，则这些功能必须包含在端点系统的第 1 层。[REQ L1.1] 任何特定端点系统所需的信任支持功能的确切性质可能会因端点系统的物理表现和许多其他设计目标（例如成本、位置、便利性、功耗、可靠性等）而有很大差异。 例如，全功能智能手机、云服务器和物联网恒温器所需的信任支持功能可能非常不同。
支持机器到机器的信任（也称为密码信任或技术信任）功能示例：
- 能够生成优质密钥的硬件模块。
- 秘密和加密材料的安全存储器。
- 足够安全的计算环境。
- 为目标部署环境提供足够安全的通信功能。
专门支持人与人之间的信任（也称为商业信任或法律信任）的功能示例：
- 将自然人关联到端点系统本身或端点系统上的数据组件（例如身份声明或可验证凭证）的身份绑定机制。 最强大的身份绑定机制之一是生物识别——识别个人的生理或行为特征（面部识别、指纹读取器、语音识别、手掌识别等）。 第 1 层将为注册、存储和处理生物特征的元语提供软硬件支持。
- 基于硬件的信任证明系统，例如那些包含在TPM中的系统，以及可以提供第1层组件安全特性的合法有效证据的其他机密计算系统。
第1层也就是信任支撑层的多样化是故意设计的，也是ToIP Stack的关键目标之一。
L2: 信任跨层
第2层是 ToIP 堆栈的信任跨层。 为满足设计原则#3（沙漏模型），只有一个需求：ToIP 端点系统必须使用 ToIP 信任跨层协议与另一个 ToIP 端点系统通信。 [REQ L2.1]
ToIP 信任跨越协议的具体需求在原文第8节中定义。
L3: 可信任务
许多应用程序可能需要比 ToIP 信任跨层直接提供的最小功能集合更复杂的信任构建功能。 当其中一个功能具有一般性，可以跨时间、空间或视角分离的多个上下文重复使用时，我们将其称为可信任务。 可信任务可以在 ToIP 堆栈的第 3 层标准化为高级别的协议。
为了在端点系统之间建立信任，可信任务层必须通过第 2 层(信任跨层)接口或通过另一个可信任务协议进行通信。 [REQ L3.1] 这直接类似于 TCP 和 UDP 如何通过 IP 通信，以及 HTTP 如何通过 TCP 通信。 第 3 层信任任务可以使用其他协议，但仅用于其他目的（因为在与其他端点系统建立信任时跳过第 2 层会破坏 ToIP Stack的信任保证）。 [REQ L3.2]
请注意，由于机密性和隐私对于第 2 层（信任跨层）是可选的，因此适用以下需求：旨在传达私有数据的第 3 层（可信任务协议）应该支持机密性和隐私。 [REQ L3.3]
只要第 4 层可信应用需要，可以有尽可能多的可信任务协议。 可信任务的一些示例包括：
- 真人验证（与在第 2 层执行的加密身份验证相反），包括生物识别验证
- 可验证凭据的交换（发布、请求、提供、呈现、撤销）
- 数字身份的配置、更新和验证
- 同意管理
- 请求和签署数字文件
- 安全消息传递
- 安全数据共享
- 任何形式的数字支付或价值交换
- 数字拍卖
- 数字公证人
L4: 可信应用
第 4 层是一个开放式应用层，适用于需要进行可信交互的任何应用程序。 第 4 层信任应用程序可以使用任意数量的第 3 层可信任务协议。 [REQ L4.1]
如果第 4 层信任应用程序不使用第 3 层（可信任务层），它必须使用第 2 层信任跨层与其他端点系统通信。 [REQ L4.2]
第 4 层是人类“接触”ToIP 堆栈的层，因此这就是设计原则 #8（信任关于人的）和#14（信任与技术具有互惠关系）发挥作用的地方。 数字信任的人类体验是如此重要，以至于第 4 层还有一个需求：第 4 层信任应用程序必须支持与该应用程序相关的任何 ToIP 定义的关于信任的直观体验。 [REQ 4.3]
小结
本文提供了ToIP首个公开审查的技术架构规范的背景和部分内容。写本文的目的有两个，一个是我自己的笔记，另一个希望对读者有所帮助。