原文信息

  • 标题：A Survey on Decentralized Identifiers and Verifiable Credentials
  • 期刊：IEEE Communications Surveys & Tutorials, Vol. 27, No. 6, Fourth Quarter 2025
  • 作者：Carlo Mazzocca, Abbas Acar, Selcuk Uluagac, Rebecca Montanari, Paolo Bellavista, Mauro Conti
  • DOI：10.1109/COMST.2025.3543197
  • URL: https://ieeexplore.ieee.org/abstract/document/10891701/

一、引言

1.1研究背景与动机

1.1.1 问题的起源

数字服务的快速普及导致全球数字身份数量急剧增加，目前世界绝大多数人口至少拥有一个数字身份。与此同时，IoT 的广泛部署与 5G/6G 网络的兴起，进一步将"数字身份"的范畴从人类扩展到了海量连接设备——这些设备同样需要唯一的数字身份才能参与数字生态系统（例如建立安全通信）。

1.1.2 传统方案的核心痛点

中心化身份的问题：

  • 依赖用户名/密码，用户为图简便倾向于弱密码，易受字典攻击和钓鱼攻击
  • 个人身份数据集中存储，一旦遭遇数据泄露，后果严重
  • 中央权威机构是单点故障（Single Point of Failure），服务可用性风险高
  • 每个服务都需要独立账号，造成"碎片化身份"景观
  • 服务提供商需投入大量资源安全保存用户数据，合规压力大

联合身份（Federated Identity）的局限：

  • 用户仍必须信任身份提供商（IdP）保管其数据
  • IdP 有能力从多个服务聚合用户信息，构建用户画像
  • 联合互信机制在大规模场景下愈发复杂

1.1.3 为什么需要 SSI？

GDPR 等隐私法规的推动，加之对数据主权的普遍诉求，催生了 自主主权身份（Self-Sovereign Identity, SSI） 范式——用户完全掌控自身身份数据，无需依赖任何中央机构或第三方。SSI 的两项核心技术标准正是由 W3C 最终规范化的 DID 与 VC。

1.2 数字身份的演进历史

论文将数字身份的发展归纳为四个时代，如下图所示（Fig. 2）：

1.2.1 中心化身份时代（Centralized Identity）

最早形态可追溯至 1988 年，IANA 负责 IP 地址有效性的认定。此后 ICANN 负责域名仲裁。这一阶段的特征是：一个中央机构管理所有身份。

1.2.2 联合身份时代（Federated Identity）

联合身份允许用户用同一套身份访问多个网站和应用，核心思想是"一次登录，到处通行"。

  • 先驱：微软 Passport 计划（允许用单一账号访问不同网站）
  • 2001 年：Sun Microsystems 联合成立 Liberty Alliance，推动开放联合身份标准
  • 今日主流：Google、Meta 等提供的 Single Sign-On（SSO）
  • 典型流程：用户向 Google/Meta 等 IdP 认证，再以其身份访问其他应用

核心缺陷：尽管减少了碎片化，用户数据控制权仍归属 IdP；大规模联合互信关系日趋复杂。

1.2.3 用户中心身份时代（User-Centric Identity）

2005 年，美国 Identity Commons 组织推动 Internet Identity Workshop（IIW），将用户置于身份管理的核心地位。由此催生了一批强调用户自主的协议：

  • OpenID / OpenID 2.0 / OpenID Connect (OIDC)
  • OAuth（开放授权）
  • FIDO（Fast IDentity Online）

用户通过各种认证器（如 JSON Web Token）和证书控制数据，这些凭据安全存储在用户设备上。

核心缺陷：仍依赖对服务提供商和权威机构的信任关系。

1.2.4 自主主权身份时代（Self-Sovereign Identity, SSI）

2012 年引入，代表数字身份进化的最新阶段。与传统模式相比，SSI 将控制权彻底交还给个人：

  • 用户决定何时、是否、以何种方式披露或修改自身数据
  • 依赖 DLT（区块链）消除对中央权威的需要，构建"无信任"（trustless）环境
  • 利用密码学确保数据安全可验证，提供透明性与不可篡改性
  • 每个个体由 DID 唯一标识，与用户控制的密钥对关联
  • 公钥通常发布于 DLT 上，任何人可独立验证身份
  • 属性和声明通过 VC 传递，第三方无需联系颁发机构即可加密验证

二、数字身份基础知识

2.1DID 技术架构详解

2.1.1 DID 结构

Fig. 3 展示了 DID 架构的主要组件及其关系。一个完整的 DID 由三个核心部分构成：

did : <method> : <method-specific-identifier>
 ↑        ↑               ↑
URI  DID方法标识    方法特定标识符

DID Method（DID 方法） 规定了 DID 的创建、解析、更新和停用流程。

DID URL 在基础 DID 上扩展了 URI 组件（路径、查询、片段），用于精确定位 DID Document 内或外部资源。

2.1.2 DID Document

每个 DID 解析为一个 DID Document——一个机器可读的 JSON-LD 文档，包含 DID Subject 的如下信息：

字段 说明
加密公钥 用于验证身份所有权
服务端点 与 DID Subject 交互的服务地址
认证参数 认证所需的配置信息
时间戳 创建和更新时间
其他元数据 扩展信息

DID 具有一致性（Consistent）和永久性（Permanent），即使个人更换服务商或平台，标识符依然有效。图 Fig. 4 展示了一个 DID 及其 DID Document 的具体示例。

2.1.3 关键角色

  • DID Subject：被 DID 标识的实体（人或非人实体）
  • DID Controller：被授权修改 DID Document 的实体，可以与 DID Subject 重合（SSI 场景），也可以不同
  • Verifiable Data Registry (VDR)：公开存储 DID Document 的可信注册表，任何验证者可通过它访问公钥等公开信息

2.1.4 DID 的三种类型

论文基于 DID 规范介绍了三种 DID 类型：

Anywise DID（任意向 DID）

  • 可用于与不特定数量的各方交互
  • 典型用途：公开身份，面向陌生人
  • 允许建立任意数量的关系，不限制交互方数量

Pairwise DID（成对 DID）

  • 只有主体本人和另一方（如某服务提供商）知晓
  • 每段关系使用独立的 DID，从根本上降低跨交互的关联风险
  • 是隐私保护的关键机制

N-wise DID（N 方向 DID）

  • 严格限定为 N 方（含主体）知晓
  • Pairwise DID 是 N=2 时的特例

2.1.5 通用解析器（Universal Resolver）

DID 通过**通用解析器（Universal Resolver）完成解析，该解析器支持多种 DID 方法体系。每个 DID 系统需要实现一个 DID Adapter，作为特定 DID 方法与通用解析器之间的接口桥梁。

2.1.6 DID 通信协议

DID 的兴起同时推动了基于 DID 的通信协议发展，实现 SSI 实体间的私密安全通信：

DID Auth 协议：允许身份所有者通过客户端应用（移动设备或浏览器）向服务提供商证明其对 DID 的控制权。协议采用**挑战-响应（Challenge-Response）**机制，可根据具体情境定制，有潜力替代传统用户名/密码认证，在身份所有者与服务提供商之间建立认证通信信道。

2.2 VC 技术架构详解

2.2.1 什么是 VC

VC（Verifiable Credential，可验证凭证）是 W3C 制定的规范，定义了一种可互操作的数据结构，能够表示可被密码学验证且防篡改的声明（claims）。VC 可无缝运行于不同平台和应用，持有者可将其存储在数字钱包中随时携带，且始终保持可验证性。

图 Fig. 5 展示了一个典型 VC 示例：允许"Example University"的所有校友在体育赛事季票上享受折扣。

2.2.2 VC 生态的主要角色

图 Fig. 6 展示了 VC 生态中的核心角色关系：

  • Holder（持有者）：控制一张或多张 VC 的实体（如个人用户）
  • Issuer（颁发者）：签发 VC 的可信实体，如政府机构或银行
  • Verifier（验证者）：需要有效凭证才能提供服务的实体，如电商网站
  • VDR：作为生态系统中介，提供标识符、密钥、VC Schema 等公开数据

重要说明：凭证通常包含敏感信息，因此一般不存储在 VDR 或中央系统上，而是在链下（off-chain）共享，以最大程度降低数据暴露风险。

2.2.3 VC 的数据结构

VC 包含以下核心元素：

元素 说明
Subject URI 主体标识符，用于获取主体公钥以验证凭证归属
Issuer URI 颁发者标识符，用于获取颁发者公钥并验证可信来源（可以是 DID）
凭证唯一 URI 全局唯一标识该凭证
声明到期条件 凭证有效期限定
加密签名 保障完整性，防止篡改

2.2.4 可验证展示（Verifiable Presentation, VP）

W3C VC 工作组还定义了 可验证展示（VP） 的概念，规定了持有者对 VC 进行签名和展示的方法。

  • VC 和 VP 均可用 JSON-LD、JSON 或 JSON Web Token 格式描述
  • 图 Fig. 7 展示了基于前述 VC 示例生成的 VP

W3C 已发布相关标准，确保 Web 上的可验证信息具备机器可验证性、隐私尊重性和密码学安全性。

2.2.5 选择性披露（Selective Disclosure）

为赋予个人对数据的完全控制权，VC 支持选择性披露其中一部分信息。多年来已发展出多种方法，通常分为以下几类：

1. Mono Claims（单一声明） 每个声明独立处理，最简单的形式。

2. Hashed Values（哈希值） 用声明的哈希摘要替代明文，验证时提供原值核验。

3. Zero-Knowledge Proofs（零知识证明，ZKP） 允许证明者在不透露任何额外信息的前提下证明某声明为真。

4. Selective Disclosure Signatures（选择性披露签名） 通过特殊签名方案实现对部分声明的可验证披露。

当前最先进方案：SD-JWT（Selective Disclosure for JWTs）

SD-JWT 通过将明文声明替换为加盐值（Salted Values）的摘要来增强隐私保护（e.g. $hash(age=20 + salt)$）。持有者披露特定信息时，同时提供原始声明及对应的盐值，验证者对比摘要确认真实性。这样，未披露的声明内容对验证者完全不可见。

2.3 可验证数据注册表（VDR）详解

2.3.1 VDR 在 SSI 中的角色

VDR 在 DID 和 VC 生态中充当受信中介，是一个存储并提供访问以下关键信息的存储库：

  • DID Documents（含公钥、服务端点、认证参数、时间戳、元数据）
  • VC Schema 及相关验证数据

当验证者需要验证 DID 或 VC 时，从 VDR 获取相关公开信息，验证以下几点：

  1. 真实性（Authenticity）：凭证确由声称的颁发者签发
  2. 完整性（Integrity）：凭证内容未被篡改
  3. 有效性（Validity）：凭证处于有效期内且未被吊销

2.3.2 VDR 的生命周期管理职能

VDR 负责 DID 和 VC 的全生命周期管理：

  • 创建与注册：实体创建新 DID 或颁发新 VC 时，与 VDR 交互完成注册
  • 更新：DID Document 发生变更时（如密钥轮换），VDR 处理相应更新操作
  • 吊销：DID 或 VC 需要作废时，VDR 执行吊销，并使系统中的状态反映变化

2.3.3 VDR 的实现方式

W3C 标准目前不规定 VDR 的具体实现方式。主流方案如下：

基于区块链（最主流）：

  • 区块链由互相引用前一区块哈希的区块构成，形成安全链条
  • 任何篡改都会导致哈希不匹配，可即时检测
  • 这一特性对于安全共享 DID Document 等信息至关重要
  • 许多区块链还支持智能合约（Smart Contract）——直接存储在区块链上的自执行程序，条件满足时自动触发
  • 区块链固有的容错性、防篡改性和可追溯性，使智能合约成为各类 DID/VC 应用中的重要技术

替代方案——信息中心网络（ICN）：

  • 一种新型网络范式，可用于实现注册表
  • 用户与边缘节点交互，通过 HTTP API 管理 DID，再由边缘节点将请求转换为对应的 ICN 流

三、安全威胁与缓解策略

尽管 DID 和 VC 提供了显著的安全和隐私优势，它们并非没有漏洞。

3.1 密钥与凭证泄露

威胁 1：私钥被攻击者通过钓鱼、恶意软件或直接盗窃等手段获取，进而冒充合法身份所有者。

缓解策略：

  • 密钥轮换（Key Rotation）：定期轮换密钥并吊销旧密钥，将泄露造成的损害降至最低
  • 多因素认证（MFA）：增强钱包访问安全性。MFA 还可要求从多台设备提交同一凭证，确保单一钱包被攻破不足以冒用凭证
  • 硬件安全模块（HSM）：将私钥存储在安全硬件中，防止未授权访问
  • 可信第三方密钥恢复：通过托管服务安全备份和恢复密钥，防止密钥丢失

威胁 2：恶意用户与他人勾结或窃取合法用户的有效凭证，向验证者冒充持有者。

缓解策略：将 VC 及其展示与身份所有者绑定。持有者的标识符（如 DID）被写入 VC，其不可篡改性防止任何修改。展示者必须证明对身份所有者私钥的知晓（仅持有者知道），才能证明凭证归属。

威胁 3：攻击者试图通过伪造合法 VC 或使用无权颁发 VC 的实体颁发的凭证来访问服务。

缓解策略：凭证必须由颁发者进行数字签名（攻击者不知道颁发者私钥，无法伪造）。每张凭证必须包含颁发者标识符，确保只有受信任的权威机构认证了声明。此外，应维护一个安全的可信颁发者注册表，记录所有可信颁发者及其授权认证的声明类型。

3.2 凭证有效性

威胁 4：VC 可能因权限丧失或到期而失效，验证者在接受凭证前必须核验其有效性。

缓解策略：

方法一：嵌入有效期 颁发者在凭证内部指定有效期，验证者直接检查是否仍在有效期内。但此方法无法处理颁发者主动吊销（如持有者失去相关权利）的场景。

方法二：借鉴 PKI 证书吊销机制

  • OCSP（在线证书状态协议）
  • CRL（证书吊销列表）

方法三：W3C Revocation List 2020

这是 W3C 专为 VC 提出的吊销位图方案：

  • 每一位（bit）对应一张 VC 的索引
  • bit = 1：对应 VC 已被吊销
  • bit = 0：对应 VC 仍然有效
  • 由于大多数凭证预计保持有效，位图中大量连续位值相同，非常适合用 ZLIB 等压缩算法处理
  • 实际效果：原始 16KB 的位图经压缩后可缩减至约 135 字节（见 Fig. 8）

3.3 隐私威胁

威胁 5：VC 可能包含超出访问特定服务所需的声明，服务提供商因此获取了多余的个人信息。

缓解策略：持有者在生成 VP 时，应只包含访问该服务所需的声明，移除不必要的部分。通过选择性披露技术，可以在不暴露整张凭证的前提下验证所披露声明的真实性。

威胁 6：即便使用选择性披露，服务提供商仍可能跨多次展示关联声明到同一个体，或与其他服务商勾结进行关联追踪。

缓解策略：

  • 使用 Pairwise DID 降低关联可能性（但不能完全消除跨多次展示的关联）
  • VC 中应避免包含持久性用户标识符（如 DID），除非颁发者标识确实需要
  • 完全不可关联性（Unlinkability）并不总是合适：例如凭证用于认证时，服务提供商需要识别重复展示以防止 Sybil 攻击
  • 可采用 Linked Unlinkability（关联的不可关联性） 方案：允许识别重复展示，但最大程度降低跨不同服务提供商的关联风险

威胁 7：VC 持有者可能无权访问凭证中某些机密信息（这些信息仅供验证者使用）。

缓解策略：VC 中的声明可使用仅授权服务提供商知晓的密钥加密，同时结合选择性披露机制。揭示声明所需的信息仅与服务提供商共享，而非持有者。

3.4 中间人攻击

威胁 8：攻击者截获并篡改合法用户与服务提供商之间的通信，可能获取展示内容或修改传输信息。

缓解策略：使用端到端加密协议保护通信内容。由于 VC 使用颁发者私钥签名，任何对其内容的修改都会被检测到。

威胁 9：攻击者截获 VP 后向不同验证者重放，冒充合法持有者获得未授权访问（重放攻击）。

缓解策略：在 VP 中嵌入 nonce 或时间戳。验证者发送一个挑战值（Challenge）作为 nonce 写入凭证，有效的 VP 必须包含该挑战值，确保与该验证者的该次会话一一对应。

四、主流实现框架对比分析

DID 和 VC 的成功实现对于 SSI 系统的广泛采用至关重要，开发者需要高效框架来简化这些技术的使用，同时符合已建立的标准。

论文中的 Table IV 提供了各主流实现的关键特性比较。

4.1 DIDKit（SpruceID）

DIDKit 是 SpruceID 提供的工具包，核心库用 Rust 实现，优势在于：

  • 内存安全
  • 更简单的依赖树
  • 与各种平台（包括嵌入式系统）的兼容性

虽然 DIDKit SDK 支持广泛的使用场景，但其对 C、Java、Android、Python 和 JavaScript 等其他语言的绑定是对 Rust 核心的包装（Wrapper），因此使用这些绑定可能比直接使用 Rust 引入更多挑战和复杂性。

DIDKit 支持通过 SD-JWT 实现选择性披露，主要功能如下：

  1. 签名和验证任何符合 W3C 标准的 VC；内置可通过任何 API 接口（包括 W3C 标准接口）访问的即用型 HTTP/HTTPS 服务器
  2. 支持并可转换两种主要的 VC 签名系统和证明格式
  3. 可处理、认证、验证、注册并确定性地生成符合 W3C 标准的多种 DID
  4. 可颁发和使用基于 Object Capabilities（ZCaps）的授权令牌

4.2 IOTA Identity Framework

IOTA Identity 框架实现了去中心化身份解决方案，同时支持与 DLT 无关的方法和专用的 IOTA 方法规范。该框架构建在 Tangle 上——一种专为 IoT 生态设计的下一代 DLT。

IOTA Identity 可随时为任意实体（包括 IoT 设备）创建新的数字身份。相关功能通过 Rust 和 Node.js（借助 WASM）提供。

验证流程：验证者通过 Tangle 上的公钥确认颁发者身份，持有者证明对其 DID 的所有权。

IOTA Identity 同样支持符合 IETF 标准的选择性披露机制，包括 SD-JWT 和 ZKSD（零知识选择性披露）。

IOTA Tangle（有向无环图 DAG）的独特优势：

特性 说明
无手续费（Feeless） IOTA 没有矿工或验证者，DID Document 等消息的存储无需交易费用，可直接在主网部署 SSI 应用，降低使用门槛
易用性 无需持有任何加密货币代币；提供简单 API，支持标准化灵活功能；框架内置 Stronghold 安全管理机密
通用 DLT IOTA 是通用目的 DLT，可将 SSI 与支付、数据流、智能合约、访问控制等其他功能集成

4.3 Hyperledger Aries

Hyperledger Aries 是 Hyperledger 生态中的开源项目，提供一套完整的工具和库，用于构建去中心化身份应用。支持 DID 和 VC 的安全存储与展示，最大化保护隐私。

Aries 设计高度灵活，支持多种协议、凭证类型、账本和注册表，并提供跨不同身份系统的互操作工具。开发者可通过集成特定应用代码来控制 Aries Agent。

目前可用的主要 Agent：

  • Aries Cloud Agent - Python：适用于所有非移动应用，已有生产部署。作为控制器旁路运行，通过 HTTP 接口通信，控制器可用任意语言实现，内嵌 Indy-SDK
  • Aries Framework - .NET：用于构建移动端和服务端 Agent，同样用于生产环境。控制器可用任意语言编写，可作为库嵌入，包含 Indy-SDK
  • Aries Static Agent - Python：不使用持久化存储的可配置 Agent，轻量简洁，适用于特定场景

安全性和性能方面，Hyperledger Aries 是去中心化身份系统中最健壮的平台之一。但对于测试场景或流程密集型环境中的认证，由于架构复杂性和较陡峭的学习曲线，Aries 可能不是最优选择。

4.4 Microsoft Entra Wallet Library

微软积极开发的 Microsoft Entra Wallet Library 是一个用于在 iOS 和 Android 平台管理 DID 和 VC 的新型库，支持将移动应用与 Microsoft Entra Verified ID 平台集成，符合 OpenID Connect、Presentation Exchange 和 VC 等多项行业标准。

隐私保护机制：默认情况下，该库为每次与依赖方的交互使用独立的 DID，防止用户行为关联，保护隐私。库还自动从原始颁发者处检索交换的 VC，简化流程同时维护凭证完整性。

支持的需求类型：

  • GroupRequirement：允许验证者或颁发者同时请求多个需求，聚合为列表
  • VerifiedIdRequirement：请求特定的 VerifiedId 作为用户主要凭证
  • SelfAttestedClaimRequirement：允许颁发者请求用户自证声明（简单字符串值）
  • PinRequirement：颁发者可在验证或颁发过程中要求用户提供 PIN
  • AccessTokenRequirement：允许颁发者请求访问令牌（通常需要外部库）
  • IdTokenRequirement：允许颁发者请求身份令牌

主要限制：访问开发者资源需注册 Microsoft 365 Developer Program 并提供个人信息；Entra Wallet 主要针对移动设备优化，限制了更广泛的使用场景。

4.5 Veramo

Veramo 是一个 JavaScript 框架，旨在简化 DID 和 VC 的使用。灵活性和模块化使其能够适应各种使用场景和工作流程。

核心是 Veramo Agent，采用插件驱动架构提供可扩展性，并与可验证数据生态系统中的新兴标准集成。

Veramo Agent 的核心功能（均通过插件实现）：

  • 创建标识符
  • 解析标识符
  • 凭证颁发
  • 凭证吊销
  • 凭证交换

Veramo 支持多平台运行：Node.js、浏览器、React Native。还提供 CLI（命令行界面），开发者可从终端快速创建 DID 和 VC 或运行本地云 Agent，简化开发和测试流程。

Veramo 还通过专用插件支持选择性披露，允许持有者选择性地揭示 VC 中的特定声明（该功能仍处于 Beta 阶段，遵循新兴 IETF 标准）。

主要限制：仅限 JavaScript，可能影响开发者在技术选型时的决策。

4.6 框架选型总结

框架 定位 适用场景 主要限制
DIDKit 通用、Web 中心 多语言项目、快速入门、HTTP API 场景 非 Rust 绑定为包装层，有额外复杂度
IOTA Identity IoT 专向 物联网设备、无手续费场景、人机混合系统 依赖 IOTA 生态
Hyperledger Aries 企业级 生产环境、复杂协议需求、多账本场景 学习曲线陡峭，架构复杂
Microsoft Entra 移动端 iOS/Android 应用、企业 SSO、移动设备管理 主要针对移动端，需 Microsoft 账号
Veramo 快速原型 JS/TS 全栈项目、浏览器应用、React Native 仅支持 JavaScript

选型要点：探索 DID/VC 标准时，DIDKit 提供了内置即用型 HTTP/HTTPS 服务器，适合初学者；Veramo 也旨在简化去中心化身份应用的创建，但 JavaScript 的限制可能影响技术决策；在 IoT 场景中，IOTA Identity 是最自然的选择；对于偏好通过移动应用管理数字凭证的用户，Microsoft Entra Wallet 提供了全面的功能支持。

五、应用领域

论文将 DID/VC 的应用领域分为五大类（见 Fig. 9）：智能交通、智慧医疗、工业、其他智慧服务、身份管理。

5.1 智能交通（Smart Transportation）

近年技术进步显著推动了智能交通系统（ITS）的发展，V2V（车对车）通信开辟了提升道路效率和安全性的新应用空间。V2V 通信的核心挑战在于车辆间缺乏信任——它们通常没有预先关系，且依赖中心化网络权威。

V2V 通信与 DID/VC：

  • MOBI Alliance 于 2019 年引入基于区块链的车辆身份（VID）标准，基于 DID 规范增强传统 VIN，兼容区块链生态
  • D-V2X 协议：去中心化 V2X 协议，用去中心化车辆 PKI（D-VPKI）替代传统 VPKI。车辆向 D-VPKI 注册随机 DID，OEM 颁发嵌入 VIN 的 VC；为保护隐私，车辆注册多个通过 ZKP 关联主 DID 的 DID，OEM 创建后删除这些子 DID；也可用安全多方计算（MPC）颁发 VC，防止 OEM 关联原始 DID
  • VDKMS：基于区块链和 SSI 原则的去中心化密钥管理系统，用于 V2X 安全通信和高效密钥管理
  • GPS 欺骗防护：车辆可从附近基础设施（如红绿灯）获取 VC 证明其位置，或通过安全数据溯源协议验证位置声明
  • 车辆声誉系统（V2X Reputation）：通过变更区块链地址同时保留声誉来实现隐私保护；通过 ZKP 在智能合约中转移声誉，防止外部观察者关联新旧地址

车辆服务（Vehicular Services）：

  • BDRA：基于 DID 和双层区块链的安全注册与认证系统。上层包含所有授权 RSU，下层包含 RSU 及其覆盖范围内的车辆；每辆车生成自己的 DID 并提交给覆盖 RSU；RSU 协作创建唯一 VC 授予车辆访问服务的权限
  • 港口卡车认证：卡车配备 SSI 凭证（如"在役车辆"），执行操作时提供必要 VC 验证授权
  • 车辆所有权委托：车主可用 Pairwise DID 向服务提供商或朋友授予临时访问权
  • 数据溯源：通过 DID 链接的签名数据版本链保障汽车数据处理链的数据溯源

电动车服务（Electric Vehicle Services）：

  • V2V 能源交易：DID 用于提交竞价和预约能源，VC 记录交易详情（成本、能源量）；卖方 DID 公开可访问用于验证合法性
  • EV 充电认证：将 DID/VC 集成到 ISO 15118-20（定义 EV 充电通信协议的标准），作为标准要求的复杂中心化 PKI 的健壮替代方案
  • 客户隐私保护：用户注册 DID 和伪 ID，伪 ID 用于生成多个后续充电会话的假名；用户和充电站互相验证对方 VC；ZKP 在不暴露额外信息的情况下验证 VC

5.2 智慧医疗（Smart Healthcare）

医疗服务（Healthcare Services）：

  • 免疫护照（COVID-19）：移动应用利用 DID/VC 提供防篡改、保护隐私的检测结果和疫苗接种认证。药房或国家卫生服务机构为血液检测结果或疫苗接种证书等基本文件颁发 VC；这些凭证在验证和医学检测完成后安全存储在公民硬件或数字钱包中；Fig. 11（入职流程）和 Fig. 12（认证流程）展示了完整数据流
  • 去中心化存储方案：部分解决方案集成 IPFS（星际文件系统）进行去中心化链下文档存储（直接在区块链上存储证书成本极高）；IPFS 存储 VC 的加密版本，仅授权实体可访问；IPFS 哈希与公民 DID 关联作为用户密钥对
  • 罕见病身份系统（RDIS）：包含 4 类参与者，各自通过 UDID（与数字档案绑定的 DID 实现）唯一标识：验证者（手动核查文件并为用户凭证作证）、消费者（需要访问患者 UDID 文档的实体，如专科医生）、患者及其代理人（当患者为未成年人或存在某些病理限制时使用）；验证者颁发并签署附加到患者 UDID 文档的证明，消费者通过智能合约验证这些证明（确认用户在验证者注册表中的存在）；每次交互记录在仅包含 DID 和时间戳的审计日志中

医疗数据管理（Healthcare Data Management）：

  • DSMAC：基于区块链和 SSI 原则的隐私感知医疗数据访问控制系统。DID 认证访问请求，根据用户 VC 中定义的角色授予或拒绝访问。紧急情况下无缝切换到**基于属性的访问控制（ABAC）**模型，权限根据 VC 中包含的上下文属性动态调整；患者在 DID Document 中创建访问控制策略并发布到区块链
  • EHR 访问控制：通过代表患者在预定义条件下共享特定信息的同意书 VC，管理对电子健康记录（EHR）的访问；个人可直接颁发 VC 决定哪些资源可被访问
  • 联邦学习（FL）：通过 VC 解决 FL 中的参与者可信度问题——允许医院作为可信权威促进各医疗机构协作训练 ML 模型而不共享原始数据；服务提供商颁发 VC 调节参与，当提交模型质量低于阈值时可吊销凭证
  • IoMT 设备认证（Internet of Medical Things）：传感器等设备必须用 DID 和 VC 注册，生成认证令牌用于与医疗提供商交互

5.3 工业应用（Industry）

智能制造（Smart Manufacturing）：

  • 智能手机防伪：制造商为每部智能手机生成唯一 DID，以 IMEI 号为属性；专用 DID 方法支持验证 IMEI DID 文档和所有权管理；VC 用于证明设备所有权
  • 数字孪生数据安全（SIGNED 框架）：数字孪生环境中每个功能单元（如设备或软件模块）配备钱包用于 VC 共享；颁发 VC 时，所有相关属性封装在声明中，通过共享密钥加密，随后存储在 VC 中；验证者可确认属性完整性并检测任何篡改，颁发者根据具体请求选择性共享信息
  • 固件更新（Gnomon 框架）：IoT 设备在交付前向身份中心注册 DID，接收 VC 用于管理软件更新；软件发布者向身份中心颁发新 VC，设备通过其 VC 请求最新软件，验证软件发布者是否授权了该更新；若 VC 引用了更新版本，设备使用 VC 中的 URL 下载更新
  • 工业联邦学习（TruFLaaS）：面向未知参与者的可信 FL 服务，通过 VC 调节参与，当模型质量低于阈值时撤销凭证
  • FlowChain：在工业 4.0 中推广 FL，使用 DID 唯一标识参与者并调节 IIoT 设备参与 FL 训练

能源分配（Energy Distribution）：

  • 区块链能源管理系统：每个用户有 DID 用于验证信用或评估他人信用同时保护隐私；能源系统运营商颁发 VC 授予用户访问微电网和 P2P 交易系统的权限；用户也可颁发 VC 确认对方已按需供电或购买量低于计划；这些 VC 构成用户信用历史存储在区块链上
  • Flex 框架：通过 DID 注册利益相关者来协调分布式能源资源；标识符促进系统运营商与零售商等利益相关者之间的互动；DID/VC 允许用户向任何授权市场参与者或系统证明其属性而不披露底层信息
  • DID-ABAC 系统（智能电网）：用 Pairwise DID 唯一标识参与者，用 VC 替代传统用户属性，在不披露敏感信息的情况下证明属性有效性

智能供应链（Smart Supply Chain）：

  • 供应链认证：每个节点可能需要认证，认证由授权机构以 VC 形式颁发；链下验证程序确认参与者满足要求后，认证机构颁发存储在 IPFS 上的 VC，生成的哈希被签名并记录在区块链上；验证者通过访问区块链哈希和 IPFS 对应数据来检索 VC（Fig. 14 展示了此流程）
  • 跨链互操作性（VSCC）：可验证供应链凭证扩展了传统 VC 数据模型，用于验证跨多个区块链追踪的资产变更，实现不同系统间的无缝数据集成
  • 软件 SBOM：将区块链与 VC 结合革新软件开发；VC 确保软件物料清单信息的真实性和完整性；监管机构可颁发 VC 证明软件供应商遵守安全开发标准和实践
  • 产品碳足迹：选择性披露使制造商可以只共享产品碳足迹相关认证的特定信息，同时保护供应商详情等商业秘密

5.4 其他智慧服务（Other Smart Services）

智慧旅游（Smart Tourism）：

  • 旅游机构认证：希望获得授权的旅游公司向监管机构提交身份申请，成功验证后获得 DID 和 VC；使用 IPFS 存储 DID Document 和 VC 以减轻区块链负担
  • 无护照旅行：游客向领事馆提供 DID 申请签证，签证以 VC 形式发放；此类 VC 允许游客在访问需要身份验证的服务（如酒店预订、租车）时共享身份信息

智慧教育（Smart Education）：

  • 数字学历证书：颁发 VC 的过程可建模为随时间颁发的子凭证序列，每个认证步骤记录在区块链上，形成依赖图，允许验证者检测恶意行为并建立公开可验证的因果关系
  • 去中心化学历验证：高等教育机构可在区块链上注册颁发的证书，联盟智能合约将注册教育机构的 DID 映射到其智能合约地址；当学术机构加入联盟时，必须部署智能合约并获得其他成员批准
  • ELMO2EDS：将 EMREX 数字凭证转换为 EBSI 文凭（适合 SSI 的数据格式），支持用户认证（Fig. 15 展示了跨大学学历认证场景）

智能家居（Smart Home）：

  • 某些情况下，外部人员（如技术员修理冰箱）可能需要访问权限
  • 由于部分智能设备缺乏直接处理 DID/VC 的能力，可将 DID/VC 处理委托给 OAuth 服务器
  • 以修冰箱为例：技术员向 OAuth 服务器提供由其公司颁发和信任的 DID 和 VC；OAuth 服务器生成授予冰箱访问权限的令牌
  • 部分智能设备有资源独立验证 VC，VC 可包含用户对设备功能的详细权限信息

声誉系统（Reputation-based Systems）：

在电商系统中，每个卖家可通过数字身份标识，购买后向客户颁发反馈 Token（作为 VC）。这些 Token 用于提交评价，确保反馈和身份信息的真实性和防篡改性。为鼓励参与，客户提交评价后从平台获得折扣令牌奖励。

智慧农业（Smart Agriculture）：

  • 农业 IoT 数据共享：部署在农田中的每个 IoT 设备被分配 DID，区块链作为基于设备属性颁发给这些设备的 VC 的来源证明
  • 通过**预言机（Oracle）**解决智能合约无法直接访问外部数据的限制——预言机在区块链生态系统和外部世界（农业 IoT）之间建立桥梁
  • 智能合约可在满足农业风险评估预定条件时自动向农民付款

5.5 身份管理（Identity Management）

用户与设备（Users and Devices）：

  • CanDID：从现有 Web 服务（社交媒体平台、网银等）安全移植身份和凭证，无需显式生成 DID 兼容凭证，同时提供密钥恢复服务
  • BIdM：区块链去中心化身份管理系统，使用单向累加器（One-way Accumulator）积累有效的密钥-值对（DID 和公钥），累加器状态存储在区块链联盟上；将身份分为主身份（DID，用于区块链网络）和影子身份（由身份提供商颁发，离线存储）
  • SmartDID：专为 IoT 环境定制的区块链分布式身份系统，具有双凭证模式和分布式证明系统，利用承诺和 ZKP 保护敏感属性隐私
  • SSIBAC：基于 XACML 规范的访问控制模型，将 VC 编码到 VP 中并映射到存储在策略检索点的访问控制策略

选择性披露的实际应用扩展：

  • 购买葡萄酒时，用户只需披露出生日期来验证年龄，其他个人信息保持私密
  • 医疗场景：患者可能需要证明保险覆盖而不透露完整病史
  • 通过 HMAC 隐藏 VC 中代表诊断记录的声明，允许患者选择性地向医疗人员披露数据

与 FIDO 集成：

  • SSI 身份框架与 FIDO 等额外认证协议集成，添加额外保护层
  • 每个用户使用 FIDO 认证器生成本地存储的密钥对作为凭证，该密钥对与用户 DID 关联
  • 对于没有外部认证设备（如 USB 令牌）的用户，**可信执行环境（TEE）**可充当 FIDO 认证器

服务与数据（Services and Data）：

  • IPFS + DID 集成：将 DID 用作内容名称，DNSlink 将 DID 绑定到内容标识符（CID）；当因内容变更生成新 CID 时，对应 DNS 记录也会更新
  • 跨链 DID 验证（JointCloud）：在连接多个云的新型云计算范式中，通过可验证声明（任何实体均可签名的数据结构）管理异构 VC；验证者执行跨链合约检索和验证声明；可验证声明、签名者和验证者被赋予信誉值以增强信任
  • 命名数据网络（NDN）中的内容广告：内容所有者使用分层 DID 作为内容名称，授权发布者向特定路由器广告内容名称前缀

六、全球监管、项目与组织

6.1 欧洲

欧洲一直是创新身份管理解决方案的先行者，使欧洲公民能够使用电子身份（eID）进行在线认证。

eIDAS（2014） 2014 年欧盟委员会发布 Regulation 910/2014（eIDAS），为欧洲公民通过标准化数字身份凭证安全访问跨 EU 在线服务奠定基础。基于联合身份模型：用户向 IdP 注册，IdP 使他们能够与信任该 IdP 的服务提供商共享身份；虽提供 SSO 体验，但存在隐私隐患——用户对数据没有直接控制权，IdP 可能从多个服务聚合信息进行用户画像。

eIDAS 2.0（2021） 为解决 eIDAS 的不足，欧盟委员会于 2021 年提出更新版本，从联合身份模型转向 SSI 模型，旨在让用户直接控制自身信息，只共享服务提供商履行请求所需的最少数据。

EU Regulation 2024/1183 + EUDIW 2024 年 5 月，EU Regulation 2024/1183 引入欧洲数字身份框架。关键要素是欧洲数字身份钱包（EUDIW），预计成为数字身份的重大转折点——预计到 2026 年有 5 亿智能手机用户定期使用 EUDIW。钱包旨在通过 SSI 系统为欧洲公民提供安全访问欧洲各地公共和私人服务（线上线下）的能力，支持开设银行账户、获取教育凭证等多种场景。在此生态中，每个 EUDIW 与一个 DID 关联，存储在 EUDIW 中的凭证采用由 eIDAS 颁发者签发的 VC 形式，验证密钥必须对任何人公开可访问以确保透明度和互操作性。

eSSIF-LaB EU 资助的欧洲自主主权身份框架实验室，专注于加速 SSI 采用，提供安全、开放、可信的框架，汇聚政府和企业等利益相关者简化 SSI 技术的实施和使用。

EBSI（European Blockchain Services Infrastructure） EU 与欧洲区块链伙伴关系（EBP）的合作项目，涵盖全部 27 个 EU 成员国以及挪威和列支敦士登，目标是建立支持无缝跨境服务的统一基础设施。显著应用：利用 DID/VC 简化教育凭证管理——博洛尼亚大学（意大利）和鲁汶大学（比利时）已参与了重点关注教育凭证验证（包括可验证学生证和学生成绩单）的试点研究。

GDPR 合规性 DID/VC 如何支持 GDPR 关键数据权利：

GDPR 权利 DID/VC 支持方式
知情权 VC 数据共享完全由用户控制，用户始终知晓数据传输对象和目的
纠正权 VC 中信息不准确时，个人可请求颁发包含正确信息的新凭证
被遗忘权 用户可随时吊销 VC 使其无法用于未来验证；选择性披露确保只共享特定交易所需的最少信息；ZKP 允许个人在不透露底层个人数据的情况下证明某些属性

6.2 北美

美国

  • 2011 年：实施国家网络空间可信身份战略（NSTIC）
  • 2016 年：DHS 认识到基于区块链的数字身份技术潜力，向该领域企业授予资助，其中一项资助促成了 W3C 内 DID 工作组的成立
  • 此后：DHS 累计提供 400 万美元专项资助中小企业 DID 领域
  • 2023 年 6 月：DHS 发布征求意见，寻求隐私保护数字凭证生态前沿解决方案，目标应用领域包括 USCIS、CBP 和 DHS 隐私办公室

加拿大

  • 数字身份与认证委员会（DIACC）：由公私部门领导者组成的非营利联盟，致力于为加拿大开发数字身份框架
  • Pan-Canadian Trust Framework（PCTF）：定义数字身份和 VC 在加拿大使用规则、标准和最佳实践的框架，旨在建立可信的可互操作数字身份生态
  • 2018 年：加拿大公共机构创建 Verifiable Organizations Network（VON），使政府和组织能够使用 VC 颁发数字许可证、许可和法人实体注册文件

6.3 南美洲

阿根廷是南美洲在 DID/VC 项目方面最活跃的国家：

  • DIDI 项目：旨在提高信任水平，打破阻碍弱势群体获取优质商品和服务的社会经济和金融壁垒
  • 2021 年：开始为 Gran Chacho 地区农民提供记录其可持续实践的 VC，这些凭证有助于形成"气候风险评分"，可向希望促进农村生产者获取金融信贷的金融机构展示
  • 米西奥内斯省批准了允许在政府管理操作中使用区块链的法律，并启动了改善数字钱包采用的项目
  • 巴西、哥伦比亚和哥斯达黎加参与 Farmer Connect 项目，利用 SSI 技术实现食品和农业供应链的端到端可追溯性

6.4 亚洲

韩国：亚洲采用 DID/VC 的领先国家之一

  • KFTC 为金融服务引入了基于区块链的数字 ID，并积极参与 DID Alliance Korea
  • 2020 年：釜山市推出 Busan Blockchain ID App，公民可使用 DID 访问各种设施（如为有三个或以上子女的家庭提供福利的"多孩家庭爱心卡"）
  • 韩国互联网安全局（KISA）是 W3C 凭证社区组成员

中国：

  • 2023 年底：公安部与区块链服务网络（BSN）合作推出 RealDID，旨在验证实名数字身份、加密个人数据并提供认证
  • 微众银行推出 WeIdentity，建立使用 DID/VC 的去中心化身份生态
  • 香港：ARTRACX Curator 平台利用区块链、DID 和 VC 为艺术品和收藏品建立数字身份，确保知识产权保护和认证

台湾：

  • 2023 年起与 W3C 和 IOTA 合作实施去中心化身份解决方案
  • Taiwan DID：为台湾公民提供居住地验证后的 VC 服务，可用于在多个国家提供不同定价和内容的数字内容订阅服务

6.5 非洲

非洲在 DID/VC 领域面临与技术先进国家类似的挑战，同时有其特殊情境：数字证书容易被 Photoshop 等工具伪造，急需在线凭证验证能力。

  • Gravity Training（南非）：与 Dock Network 合作采用 VC
  • Diwala：已在非洲 9 个国家的 50 余个机构促进了 VC 的使用
  • 塞拉利昂 NDIP（2019）：采用 Kiva Protocol，利用 DID/VC 实现面向公民的快速、经济、安全的身份验证
  • 肯尼亚出生登记：使用 DID/VC 使亲属能够通过智能手机与卫生工作者互动，实现高效出生登记并将母亲与婴儿关联

6.6 澳大利亚与新西兰

澳大利亚：

  • 有许多正在进行和拟议中的项目，专注于将政府颁发的 VC 存储在设备原生或州政府钱包和应用中
  • 多种使用场景，特别强调就业和教育（如应届毕业生申请工作或更高学位时可能需要提供 VC 作为学历证明）
  • 正在出现跨司法管辖区使用场景，公民可能需要提供由一个或多个州级司法管辖区颁发的凭证

新西兰：

  • 2023 年初通过《数字身份服务信任框架（DISTF）法案》，为开放资质认定计划建立法律基础
  • CVS-NCNZ（新西兰护理委员会凭证验证服务）：使在境外接受教育和获得执照的护士能够核实和认证其凭证，在新西兰合法执业

七、挑战与未来研究方向

7.1 标准化（Standardization）

核心问题：

虽然 DID 和 VC 已由 W3C 标准化，但仍存在若干内容和协议标准化方面的挑战：

  • DID 方法规范不一致：不同 DID 方法在格式、完整性、信息密度乃至版本管理上存在差异，给互操作性带来显著挑战
  • VC 标准化滞后：虽然有针对特定领域的努力（如 EBSI 针对欧洲跨大学教育凭证），但许多应用领域仍处于采用早期。例如 IoT 缺乏设备 VC 数据结构标准，阻碍 IoT 网络间的互操作性；不同行业若采用领域特定标准（如医疗专用 VC），若设计时未考虑互操作性将导致碎片化
  • 协议层面缺乏共识：密码算法、密钥管理实践或 DID/VC 生命周期管理标准尚无共识；许多关键安全方面仍是非规范性的；监管和法律框架仍在演变中，进一步使跨司法管辖区的互操作性和合规性复杂化

W3C、ISO 标准和 Trust over IP（ToIP）等联盟正致力于通过推动统一框架和开展互操作性测试来应对这些挑战。

7.2 可扩展性（Scalability）

正面因素： 去中心化架构本身比中心化系统具有更好的可扩展性，因为它不依赖经常成为瓶颈的中央权威。用于存储 DID Document 的 DLT 对可扩展性的影响并不像想象中那么大——验证发生在链下，DLT 仅用于存储和检索包含颁发者和持有者公钥的 DID Document。信任部分颁发者子集的验证者可以在本地存储其公钥，将账本交互降至最低。

潜在瓶颈：

  • 随着数字身份数量的指数级增长，账本存储和维护需求增加，查询效率可能降低
  • DLT 系统在高峰活动期可能面临网络拥塞，减慢数据检索并提高运营成本

改进方向：

  • 索引（Indexing）：加快 DID Document 查找
  • 缓存（Caching）：本地存储频繁访问的数据，减少账本交互
  • 分片（Sharding）：将账本分割为更小、更易管理的部分，支持并行访问并减少延迟

选择性披露的可扩展性： 预计到 2026 年，身份所有者将管理来自各个组织的多张 VC，因此必须开发机制使持有者在选择性披露其声明子集的同时保持最少的额外信息。这些协议还通过减少验证时传输的数据量来降低对通信信道的压力，最小化带宽使用并提升验证效率。

吊销可扩展性： 随着 VC 颁发数量增长，高效吊销机制变得日益重要。密码学累加器（Cryptographic Accumulators）和尾文件（Tail Files）是优化吊销管理的有前景方法。

7.3 可用性（Usability）

管理新形式数字身份的复杂性可能是普通用户采用的重大障碍。

EU 的具体要求：到 2026 年，所有 EU 成员国必须开发安全且用户友好的工具，允许欧洲公民轻松管理其数字身份，用于在线和线下（如通过蓝牙或 NFC）访问公共和私人服务；该工具将集成从学术凭证到驾照等各类数字文件。

设计要求：

  • 直观界面，抽象底层技术复杂性
  • 用户可通过简单明了的选项管理凭证并在验证时控制数据共享
  • 同意管理必须用户友好，清晰说明共享个人信息的影响
  • 可视化工作流和逐步引导的 VC 展示流程使交互无缝
  • 跨平台互操作性，用户无需不同钱包即可访问多种服务
  • 凭证生命周期的自动化功能（续期通知、自动更新、吊销或到期警告）
  • 跨设备同步（移动端、桌面端等）
  • 需考虑区域特定法律要求（如 EU 和美国不同的隐私法律）

7.4 集成（Integration）

挑战：

DID/VC 代表数字身份管理的范式转变，与现有数字身份生态系统的集成既是机遇也是挑战：

  • 目前愿意颁发 VC 的可信实体仍然有限
  • 传统数字凭证颁发者最初可能不愿意颁发签名变体（如 VC）
  • 遗留系统的惯性以及传统与去中心化凭证流程间的无缝互操作性将是关键

机遇：

  • 社交媒体利用 DID/VC 创建经过验证的账户，解决机器人活动问题——VC 允许个人证明创建账户所需信息的真实性，通过选择性披露只揭示必要信息保护用户隐私
  • 政府可用 VC 提供安全防篡改的身份验证，同时给予公民对数据更大的控制权

短期过渡方案：

  • 开发从现有未修改服务中的可用数据构建 VC 的新方法（如 DECO、Town Crier）
  • DIDComm 等互操作框架解决编程语言、供应商和网络差异带来的挑战
  • 开发健壮的 API 和 SDK 使钱包提供商能够与各种服务无缝集成

7.5 安全与隐私（Security and Privacy）

DID 管理相关挑战：

  • DID Controller 的潜在漏洞：授权第三方管理 DID Document 引入了安全隐患，DID Controller 可能通过生成新密钥对并修改 DID Document 中的公钥来冒充 DID Owner，需要强健的授权和审计机制
  • 密钥轮换的局限性：当前公钥通常注册在区块链上对网络节点公开可见。私钥泄露时，DID 所有者需生成新密钥对并发布用旧密钥签名的新公钥，但密钥泄露的不可预测性使密钥轮换的保护存在根本性时间窗口。应重点研究能够动态响应密钥泄露的灵活轮换机制，支持自动检测和立即吊销，而非仅依赖预防性更新；将 MFA（如 OTP）与密钥轮换集成可增加额外安全层

VC 吊销的研究现状：

  • 研究空白：目前仅有一篇论文专门提出针对 IoT 网络的新型高效 VC 吊销机制（EVOKE），VC 吊销领域的研究整体欠缺

现阶段唯一存在的提议规范（Revocation List 2020）尚未达到 W3C 正式标准状态，仍处于 W3C 标准轨道上。该领域存在大量未探索的研究机会：

  • 当前方案在高吞吐量环境或受限设备（如 IoT 网络）中的可扩展性欠缺
  • 利用密码学累加器和 ZKP 可进一步增强可靠性和安全性
  • 跨各种去中心化系统可互操作的吊销解决方案也是有前景的研究方向

合规性（Accountability）：

在确保隐私的同时遵守 KYC（了解你的客户）和 AML（反洗钱）等现有法规对 DID 构成重大挑战。利用 DID 的现代系统应能够筛查系统用户，识别和验证与用户相关的凭证，对照制裁名单等各类名单筛查个人以确定是否需要采取预防措施（如黑名单）。

SD-JWT 的隐私局限：

虽然 SD-JWT 是被广泛接受的方案，但仍存在一些挑战：

  • 凭证大小随声明数量线性增长，对终端用户存储需求影响显著
  • SD-JWT 虽然隐藏了隐藏声明的内容，但仍披露了包含的确切声明数量，引入了隐私隐患——攻击者可能基于未披露声明的数量推断敏感信息（推断攻击）

八、核心概念总结

DID   = 全局唯一 + 加密可验证 + 用户自控 + 无需中央机构 的标识符
VC    = 防篡改 + 可密码验证 + 支持选择性披露 的声明凭证  
VP    = 持有者将一个或多个 VC 打包签名后的展示形式
VDR   = 存储 DID Document、VC Schema 等公开信息的受信注册表
SSI   = 以 DID + VC + DLT 为支柱的自主主权身份体系

SSI 核心三角：
  Issuer（颁发者）→ 签发 VC → Holder（持有者）
  Holder → 展示 VP → Verifier（验证者）
  Verifier → 查询 VDR → 验证颁发者公钥与 DID Document

DID/VC 的价值不局限于 SSI：凡是需要去中心化验证、防篡改记录或细粒度隐私控制的场景（无论是人、车辆、IoT 设备还是软件组件），这两项技术都具备显著的应用潜力。

参考资料