问题所在：跨组织凭证交换中的元数据泄露
当可验证凭证跨组织边界交换时，元数据会泄露身份信息：
示例：医疗凭证交换
Alice（患者）希望 A 医院将她的病历共享给 B 医院。
传统方案：
- Alice 请求：“A 医院，请把我的病历发送给 B 医院”
- A 医院的系统会知道：Alice 请求转诊到 B 医院（暴露了她选择的医疗机构）
- 网络观察者会看到：A 医院 → B 医院的流量（暴露了患者的就诊轨迹）
- B 医院会知道：请求来自 A 医院（暴露了此前的就诊机构）
泄露的元数据：
- ❌ Alice 去过哪些医院
- ❌ 转诊的时间点（暴露健康事件的发生时间）
- ❌ 医疗机构网络（聚合数据揭示 Alice 的健康就诊轨迹）
即使凭证内容已加密，这一问题依然存在。
为什么这很重要
元数据本身也是数据：
- 监控：跨患者聚合元数据能揭示健康趋势、人口统计特征、谁在治疗谁
- 关联：将 Alice 的医院就诊记录与药房记录、雇主健康计划、保险理赔关联起来
- 歧视：健康保险公司在网络元数据中看到”Alice 去过癌症中心”——拒绝承保
- 竞争情报：医院能看到患者转诊去了哪些竞争对手那里——这是有价值的商业数据
根本问题在于： 凭证交换需要路由——而路由会暴露谁在何时与谁通信。
Trust Spanning Protocol（TSP） 解决了这个问题：一个路由层，能在不向中间节点甚至参与者本身暴露路由元数据的情况下，跨组织边界传递凭证。
什么是 Trust Spanning Protocol？
TSP 是由 W3C Credentials Community Group 设计的面向可验证凭证的元数据私密路由协议，并由 Affinidi 率先在生产环境中实现。
核心特性：
- 元数据隐私：中间节点无法看到发送方、接收方或凭证类型
- 不可关联性：来自同一发送方的多次凭证交换无法被相互关联
- 跨组织路由：无需合并目录即可跨组织边界工作
- 信任注册表集成：在不暴露路由信息的前提下验证路由权限
- 生产就绪：无需可信初始设置，无需区块链，无需中央清算机构
TSP 不是：
- ❌ 一种传输协议（它使用 DIDComm 作为传输层）
- ❌ 一种凭证格式（可与任何 W3C VC 配合使用）
- ❌ 一种信任模型（使用信任注册表进行验证）
TSP 是： 一个位于 DIDComm（传输层）与可验证凭证（内容层）之间的路由层，确保跨组织交换过程中的元数据隐私。
TSP 的工作原理：高层流程
场景：跨医院凭证转移
Alice 希望 A 医院将她的医疗凭证发送给 B 医院。
不使用 TSP（元数据泄露）：
Alice → A 医院: "把我的凭证发给 B 医院"
[A 医院看到: Alice → B 医院]
A 医院 → B 医院: [凭证]
[网络观察到: A 医院 → B 医院]
[B 医院看到: 来自 A 医院]泄露的元数据： Alice 的选择、医院间的关系、时间点。
使用 TSP（元数据私密）：
Alice → TSP 中继节点 1: [加密内容: "路由至 B 医院"]
[中继节点 1 看到: 来自 Alice 的消息，下一跳 = 中继节点 2]
[中继节点 1 看不到: 最终目的地或 A 医院的参与]
TSP 中继节点 1 → TSP 中继节点 2: [加密内容: "路由至 B 医院"]
[中继节点 2 看到: 来自中继节点 1 的消息，下一跳 = B 医院]
[中继节点 2 看不到: 原始发送方或 A 医院的参与]
TSP 中继节点 2 → B 医院: [加密凭证]
[B 医院看到: 凭证已送达]
[B 医院看不到: 来自 A 医院，或者是 Alice 发起的请求]受到保护的元数据：
- ✅ 中继节点只能看到：上一跳 → 下一跳（类似 Tor）
- ✅ B 医院看到：凭证，但看不到发送方
- ✅ A 医院看到：凭证已发送，但（可选地）看不到接收方
- ✅ 网络观察者看到：中继节点之间的流量，无法关联 Alice 的多次交换
TSP 架构：分层隐私保护
第 1 层：DIDComm 传输层（加密）
DIDComm 为消息提供端到端加密：
- 发送方使用接收方的公钥加密消息
- 只有接收方能够解密
- 网络观察者只能看到加密的数据块
但是： DIDComm 的路由会暴露元数据——每个中继节点都能看到发送方 DID → 接收方 DID。
第 2 层：TSP 路由（元数据私密）
TSP 用洋葱路由包装 DIDComm：
-
洋葱加密：消息被分层加密（类似 Tor）
- 最外层：为中继节点 1 加密（包含下一跳 = 中继节点 2）
- 中间层：为中继节点 2 加密（包含下一跳 = B 医院）
- 最内层：为 B 医院加密（包含凭证）
-
每个中继节点剥离一层：
- 中继节点 1 解密外层 → 看到”下一跳 = 中继节点 2” → 转发
- 中继节点 2 解密中间层 → 看到”下一跳 = B 医院” → 转发
- B 医院解密内层 → 收到凭证
-
没有任何一个中继节点能看到完整路径：
- 中继节点 1 只知道：消息来自 Alice，下一跳 = 中继节点 2（不知道 B 医院是最终目的地）
- 中继节点 2 只知道：消息来自中继节点 1，下一跳 = B 医院（不知道是 Alice 发送的）
- B 医院只知道：凭证已送达（除非凭证本身透露，否则不知道是 Alice 或 A 医院发起的）
第 3 层：信任注册表集成
问题： B 医院如何信任凭证的路由路径？
解决方案： TSP 与信任注册表（TRQP）集成：
- 每个中继节点都在信任注册表中注册其被授权的路由能力
- B 医院查询：“这份凭证的路由路径是否有效？” → 信任注册表确认中继节点已获授权
- 元数据隐私得以保持：信任注册表的查询会显示凭证已送达，但不会透露路由细节
TSP 消息结构：洋葱分层
示例：Alice → B 医院（经过 2 个中继节点）
第 4 层（最内层）：凭证载荷
{
"type": "VerifiableCredential",
"issuer": "did:webvh:hospital-a",
"credentialSubject": {
"id": "did:webvh:alice",
"medicalRecord": "..."
},
"proof": { ... }
}加密对象：B 医院的公钥
第 3 层：中继节点 2 的指令
{
"nextHop": "did:webvh:hospital-b",
"payload": [第 4 层加密数据块]
}加密对象：中继节点 2 的公钥
第 2 层：中继节点 1 的指令
{
"nextHop": "did:webvh:relay-2",
"payload": [第 3 层加密数据块]
}加密对象：中继节点 1 的公钥
第 1 层（最外层）：Alice 发送
{
"from": "did:webvh:alice",
"to": "did:webvh:relay-1",
"payload": [第 2 层加密数据块]
}每一跳的处理过程：
-
中继节点 1 收到消息：
- 用自己的私钥解密第 2 层
- 看到：
nextHop = "did:webvh:relay-2" - 看不到：B 医院（加密在第 3 层）、凭证（加密在第 4 层）
- 将第 3 层数据块转发给中继节点 2
-
中继节点 2 收到消息：
- 用自己的私钥解密第 3 层
- 看到：
nextHop = "did:webvh:hospital-b" - 看不到：Alice（第 3 层不含发送方信息）、凭证（加密在第 4 层）
- 将第 4 层数据块转发给 B 医院
-
B 医院收到消息：
- 用自己的私钥解密第 4 层
- 看到：来自 A 医院的凭证（如果凭证包含签发者 DID）
- 看不到：是 Alice 发起的（除非凭证将她列为主体）、中继路径
结果： 没有任何一方能看到完整路径。中继节点只能看到自己所处的那一段。
元数据隐私特性
1. 不可关联性
来自 Alice 的两次凭证交换，中继节点无法将其关联起来：
- 第一轮：Alice → 中继节点 1 → 中继节点 2 → B 医院（凭证 A）
- 第二轮：Alice → 中继节点 3 → 中继节点 1 → C 医院（凭证 B）
中继节点 1 无法判断：
- 两次请求都来自 Alice（路径不同）
- 两次交换之间是否存在任何关联（不可关联）
原理： 每次交换都使用不同的路径、不同的临时密钥、不同的时间点。
2. 发送方隐私
除非凭证本身透露信息，否则接收方（B 医院）不会得知是谁发起了这次凭证交换。
示例：
- 凭证包含：
"issuer": "did:webvh:hospital-a"→ B 医院得知签发者 - 凭证包含：
"credentialSubject.id": "did:webvh:alice"→ B 医院得知凭证主体 - 但是： 凭证不会包含路由元数据（谁通过 TSP 发送的、经过了哪些中继节点）
应用场景： 举报人凭证——签发者确认真实性，但接收方不知道是谁递送的。
3. 接收方隐私
除非 TSP 被配置为透露信息，否则发送方（Alice）不会得知谁接收了该凭证。
示例：
- Alice 通过 TSP 发送凭证
- 中继节点 2 将其送达 B 医院
- Alice 只知道：凭证通过中继节点 1 发送 → (路径的其余部分被隐藏)
应用场景： 雇主凭证验证——员工发送凭证，但不知道是哪家背景调查服务对其进行了验证。
4. 中继节点隐私
每个中继节点只知道上一跳 + 下一跳——不知道完整路径、发送方或接收方。
示例：
- 中继节点 1 知道：消息来自 Alice → 转发给中继节点 2
- 中继节点 1 不知道：中继节点 2 会转发给 B 医院，也不知道凭证内容
结果： 攻破一个中继节点只会暴露一段路径，而非完整路径。
信任注册表集成：路由权限验证
问题： B 医院如何信任路由路径？
没有信任注册表时：
- 中继节点未经身份验证——任何人都可以运行一个中继节点
- 恶意中继节点可能注入虚假凭证、丢弃消息或监视流量
有信任注册表（TRQP）时：
-
中继节点注册：每个中继节点在信任注册表中注册：
- 中继节点 DID：
did:webvh:relay-1 - 已授权的能力：
["tsp-routing", "healthcare-credentials"] - 运营方：组织名称、司法辖区
- 中继节点 DID：
-
路由验证：B 医院收到凭证后，查询信任注册表：
- “这份凭证是否经由已获授权的中继节点路由？”
- 信任注册表回应：“是的，中继节点 1 和 2 已获授权用于医疗 TSP 路由”
-
吊销：若某中继节点被攻破，信任注册表将其标记为无效：
- 下一份经由该受损中继节点路由的凭证 → B 医院将其拒绝
元数据隐私得以维持：
- 信任注册表查询会显示：“凭证经由 TSP 送达”
- 信任注册表查询不会显示：使用了哪些具体的中继节点、发送方、时间点
TSP 与其他方案的对比
TSP 与直接凭证交换
| TSP | 直接交换 | |
|---|---|---|
| 元数据隐私 | ✓ 中继节点隐藏路径 | ✗ 接收方能看到发送方 |
| 不可关联性 | ✓ 无法关联多次交换 | ✗ 发送方 DID 会关联所有交换 |
| 抗监控能力 | ✓ 网络观察者只能看到中继流量 | ✗ 网络能直接看到 A → B |
| 复杂度 | ⚠ 存在洋葱路由开销 | ✓ 简单 |
| 延迟 | ⚠ 多跳（+100-200毫秒） | ✓ 直连（低延迟） |
何时使用 TSP： 元数据隐私至关重要的跨组织凭证交换场景（医疗、举报、敏感验证）。
何时使用直接交换： 同一组织内、低延迟、不要求元数据隐私的场景。
TSP 与 Tor 的对比
| TSP | Tor | |
|---|---|---|
| 应用场景 | 凭证路由 | 网页浏览匿名性 |
| 传输方式 | DIDComm（结构化消息） | TCP 流（任意数据） |
| 信任模型 | 信任注册表 (TRQP) | Tor 目录 (共识机制) |
| 凭证验证 | ✓ 原生支持 (信任注册表) | ✗ 不感知凭证 |
| 中继节点激励 | 注册的组织 (合规驱动) | 志愿者 (利他驱动) |
| 生产就绪度 | ✓ Affinidi 已上线 | ✓ 成熟 (20+ 年历史) |
TSP 借鉴了 Tor 的思路： 洋葱路由、多跳转发、不可关联性。
TSP 与 Tor 的不同之处： 原生支持凭证、集成信任注册表、企业级部署模式。
TSP 与基于区块链的路由对比
| TSP | 区块链路由 | |
|---|---|---|
| 元数据隐私 | ✓ 洋葱路由 | ✗ 所有交易均公开 |
| 延迟 | ⚠ 多跳 (200毫秒) | ✗ 区块确认 (数秒至数分钟) |
| 成本 | ✓ 免费 (中继运营方) | ✗ 每笔交易需付 Gas 费 |
| 可扩展性 | ✓ 取决于中继吞吐量 | ✗ 受限于区块链吞吐量 |
| 对监管友好 | ✓ 符合 GDPR (链下) | ⚠ 不可变的公开账本 |
区块链并不适合用于元数据私密路由——所有交易都是公开的，速度慢，成本高。
Affinidi 的 TSP 实现：首个投入生产的实现
Affinidi 是首家在生产环境中部署 TSP 的公司（2025 年）：
架构
- Agent Gateway：构建 TSP 洋葱路由消息
- Affinidi Messaging：DIDComm 传输层
- 信任注册表：通过 TRQP 验证中继节点权限
- 中继网络：由 Affinidi 及合作伙伴（医疗机构、合规组织）运营
应用场景
-
跨医院凭证转移（医疗）
- 患者凭证在医院之间路由，不暴露患者的选择
- 中继节点由区域健康信息交换机构（HIE）运营
-
可复用 KYC（金融）
- A 银行签发 KYC 凭证 → B 银行验证
- TSP 隐藏：Alice 选择了 B 银行（竞争情报）
-
雇佣关系验证（人力资源）
- 员工凭证从 A 公司 → B 公司
- TSP 隐藏：员工已离开 A 公司（减少挖角行为）
中继运营方
谁在运营 TSP 中继节点：
- ✅ Affinidi（引导网络）
- ✅ 医疗机构（符合 HIPAA 的 PHI 路由中继）
- ✅ 金融机构（符合监管要求的 KYC/KYB 路由中继）
- ✅ 政府数字身份项目（国家级中继网络）
激励机制：
- 合规：受监管行业需要元数据私密路由（GDPR、HIPAA）
- 竞争优势：早期采用者能吸引重视隐私的用户
- 生态参与：中继运营方加入信任注册表，获得授权地位
局限性与权衡
1. 延迟开销
多跳路由会增加延迟：
- 直接凭证交换：约 50 毫秒（本地网络）到约 200 毫秒（跨区域）
- TSP（3 跳）：额外增加 100-200 毫秒开销 → 总计 150-400 毫秒
缓解措施：
- 仅在隐私至关重要的交换中使用 TSP
- 优化中继节点布局（地理邻近性）
- 缓存中继路径（减少路径发现的开销）
2. 中继信任假设
TSP 依赖于诚实的中继节点：
- 被攻破的中继节点可能丢弃消息、延迟送达或记录元数据（仅限一跳的信息）
- 合谋：若多个中继节点合谋，可能会去匿名化路径
缓解措施：
- 信任注册表对中继节点进行审查（监管合规、审计）
- 多中继路径（攻破一个中继节点只会暴露一跳信息）
- 中继轮换（每次交换使用不同路径）
3. 基于时序的关联分析
流量分析： 如果攻击者能观察全部网络流量，可以进行关联：
- 消息在时间 T 进入中继节点 1
- 消息在时间 T+100毫秒 从中继节点 2 送出 → 很可能是同一条消息
缓解措施：
- 填充（在每个中继节点添加随机延迟）
- 伪装流量（中继节点发送掩护流量以混淆真实消息）
- 批处理（中继节点将多条消息一起转发）
权衡： 填充/批处理会增加延迟。
4. 并非端到端匿名
TSP 提供的是元数据隐私，而非匿名性：
- 凭证内容可能透露发送方（签发者 DID）或接收方（凭证包含目的地信息）
- TSP 隐藏的是路由元数据，而非凭证内容
若需要匿名性： 可将 TSP 与零知识证明（BBS+ 选择性披露）结合，以隐藏凭证内容。
TSP 实践：代码示例
简化的 TSP 消息构建过程（概念示意）：
// 步骤 1: 构建凭证载荷
const credential = {
type: "VerifiableCredential",
issuer: "did:webvh:hospital-a",
credentialSubject: { id: "did:webvh:alice", record: "..." },
proof: { ... }
}
// 步骤 2: 定义路径 (发送方选择中继节点)
const route = [
{ did: "did:webvh:relay-1", publicKey: relay1PubKey },
{ did: "did:webvh:relay-2", publicKey: relay2PubKey },
{ did: "did:webvh:hospital-b", publicKey: hospitalBPubKey }
]
// 步骤 3: 洋葱加密 (从最内层到最外层)
let payload = encrypt(credential, hospitalBPubKey) // 第 4 层
payload = encrypt({ nextHop: route[2].did, payload }, relay2PubKey) // 第 3 层
payload = encrypt({ nextHop: route[1].did, payload }, relay1PubKey) // 第 2 层
// 步骤 4: 发送给第一个中继节点
await didcomm.send({
from: "did:webvh:alice",
to: route[0].did,
payload: payload
})
// 中继节点 1 收到消息，解密第 2 层，看到 nextHop = relay-2，转发
// 中继节点 2 收到消息，解密第 3 层，看到 nextHop = hospital-b，转发
// B 医院收到消息，解密第 4 层，获得凭证Affinidi SDK 对此进行了封装——开发者只需调用：
await affinidi.sendCredentialViaTSP({
credential: myCredential,
recipient: "did:webvh:hospital-b",
privacyLevel: "high" // 自动选择 3 跳路径
})TSP 的未来
短期 (2026-2027 年)
- ✅ 生产环境部署 (Affinidi 已上线)
- ⏳ 医疗行业采用 (区域 HIE 中继网络)
- ⏳ 金融服务试点 (KYC/KYB 路由)
- ⏳ W3C 标准化 (TSP 规范最终定稿)
中期 (2027-2029 年)
- ⏳ 政府中继网络 (国家数字身份项目)
- ⏳ 移动优先中继 (低功耗设备作为中继节点)
- ⏳ TSP + ZKP (结合元数据隐私 + 内容隐私)
- ⏳ 中继激励层 (代币化的中继运营方)
长期 (2029 年以后)
- ⏳ 全球 TSP 网络 (跨司法辖区的联合中继网络)
- ⏳ 后量子 TSP (抗量子的洋葱加密)
- ⏳ 面向物联网的 TSP (设备间的凭证路由)
快速上手 TSP
Affinidi 的 TSP 已在生产环境中上线：
- 通过 TSP 发送凭证：
affinidi.sendCredentialViaTSP() - 运营一个中继节点：在信任注册表中注册，加入中继网络
- 验证路由权限：通过 TRQP 查询信任注册表
文档：
相关资源
技术深度解析
- DIDComm 消息传递 - TSP 的传输层
- 可验证凭证 - TSP 所路由的内容
- 信任注册表与 TRQP - 中继节点如何被验证
相关解决方案
总结
Trust Spanning Protocol（TSP） 为可验证凭证提供元数据私密路由：
核心特性：
- ✅ 洋葱路由（类似 Tor）对中继节点隐藏完整路径
- ✅ 不可关联性防止跨交换的关联分析
- ✅ 信任注册表集成在不暴露路径的情况下验证中继权限
- ✅ 生产就绪（Affinidi 于 2025 年率先实现）
权衡取舍：
- ⚠ 延迟开销（多跳增加 100-200 毫秒）
- ⚠ 中继信任假设（需要诚实的中继节点）
- ⚠ 面对全局攻击者时易受流量分析影响（可通过填充/批处理缓解）
何时使用 TSP：
- 元数据隐私至关重要的跨组织凭证交换
- 医疗（HIPAA）、金融（KYC）、雇佣关系（竞争情报）
- 举报、敏感验证、抗监控场景
Affinidi 使用 TSP 的场景：
- Affinidi Messaging（带 TSP 路由的 DIDComm 传输）
- Agent Gateway（构建洋葱路由消息）
- 信任注册表（通过 TRQP 验证中继权限）
结果： 可验证凭证跨组织边界交换时具备元数据隐私——没有任何一方能看到完整路径，中继节点无法关联多次交换，网络观察者无法进行监控。