论文：A Survey on Credential Revocation and DID Deactivation in Self-Sovereign Identity Systems 来源：IEEE Access, Volume 14, 2026（收稿 2025-12-12，接收 2025-12-26） 作者：Younho Lee（首尔科学技术大学）、Hojune Shin（首尔科学技术大学）、Daeseon Choi（崇实大学，通讯作者） DOI：10.1109/ACCESS.2025.3649792

一、论文定位与贡献

本文是第一篇专门聚焦 SSI（自主主权身份）凭证与 DID 撤销机制的全面综述，采用叙事性文献综述（NLR）方法，覆盖学术研究、W3C/IETF 标准及 Hyperledger Indy 等商业生态部署。

主要贡献：

  • 提出 VC 撤销的四类结构化分类框架：列表式、累加器式、正向确认、治理感知，并独立覆盖 DID 注销
  • 评估安全性、隐私性与性能的权衡，弥合理论方案与实际部署之间的差距
  • 识别若干持续性挑战：隐私与问责的平衡、离线验证、密钥泄露处理、后量子就绪性、监管合规

二、基础概念

SSI信任三角（Triangle of Trust）

		Issuer（发行者）
        /               \
  颁发 VC               发布公钥/撤销信息
      /                   \
Holder（持有者）  ←——VP——→  Verifier（验证者）
  保管凭证，                查询撤销状态
  选择性披露               （从 VDR 获取，不联系 Issuer）

SSI 系统围绕三个核心角色运作：

Issuer（颁发者）：对主体做出权威声明并颁发 VC 的实体，包括政府机构、教育机构、雇主、医疗机构等。Issuer 用私钥对 VC 进行密码学签名，使其可被独立验证，无需与颁发机构持续通信。这一"颁发后独立性"特征既是 SSI 的核心优势，也构成了撤销机制的根本挑战——Verifier 无法在验证时实时询问 Issuer 当前状态。

从撤销角度，Issuer 承担以下职责：管理签名密钥对；向 VDR（可验证数据注册表）发布公钥与撤销信息；在凭证失效时触发撤销流程；遵守凭证元数据标准。Issuer 同时需要制定撤销策略，明确触发事件（员工离职、执照暂停、密钥泄露）、处理时间线、撤销粒度（单个凭证 vs 批量）及监管合规要求。

Holder（持有者）：在数字钱包中管理一张或多张 VC，自主决定向谁披露何种信息的个体或机构。Holder 在撤销机制中处于双重位置：既可能是被撤销的对象，也需主动向 Verifier 证明自身凭证的有效状态（提供非撤销证明）。

Holder 在撤销问题上面临利益冲突：当私钥被盗时希望立即撤销；而当凭证因离职或执照暂停被撤销时，则可能希望存在宽限期。设计健全的系统确保 Holder 无法控制撤销状态——Verifier 直接从可信来源（签名状态列表或密码学累加器）检查状态，Holder 仅提供验证所需的最少信息。

在使用累加器或状态列表时，钱包通常缓存一个小的见证值（witness），使访问控制系统可在不获取额外信息的前提下确认"仍然有效"。在网络断开时，该见证值支持一个策略约束的短暂宽限窗口；恢复连接后再对当前状态制品进行刷新。

Verifier（验证者）：接收并审查 VP（可验证陈述）并决定是否信任相关声明的一方。验证流程包括：检查 Issuer 的公钥签名、有效期、撤销状态，并做出接受或拒绝决定。Verifier 与 Issuer 之间的信任关系通过治理安排或监管监督预先建立。

Verifier 面临实时撤销状态不一定可获取的问题——注册表可能因维护而离线，本地网络可能中断。此时 Verifier 只有缓存数据，需要基于风险评估做出决策：高风险交易直接实时确认撤销状态；低风险交易可通过缓存检查。

去中心化标识符（DID）

DID（去中心化标识符）：格式为 did:method:identifier，解析为包含公钥、服务端点与认证方法的 DID Document，通常存储于 VDR。DID Document 中与撤销直接相关的组件包括：公钥（用于签名验证）、服务端点（用于接收撤销通知）、能力委托机制（在紧急撤销场景中可授权他人代为操作）。

不同 DID 方法对撤销的影响存在显著差异：

DID 方法 存储机制 撤销特点
did:web:example.com:users:alice HTTPS/DNS 实现简单，但依赖域名控制的持续性，域名到期可能导致控制权丧失
did:ethr:0x123456789... 以太坊区块链 强防篡改性，但频繁更新面临吞吐量限制与交易成本
did:indy:sovrin:WRFXP.. Hyperledger Indy 专为身份设计，内置完善的撤销支持
did:key:z6MkhaKg.bz 无外部存储 DID 直接派生自公钥，撤销等价于密钥撤销

可验证凭证（VC）与可验证展示（VP）

VC（可验证凭证）：包含声明与元数据的数字凭证，由 Issuer 密码学签名，无需实时通信即可验证。与撤销相关的关键字段：credentialStatus 字段引用外部撤销机制（状态列表或累加器），是 Verifier 检查撤销状态的入口；proof 部分包含 Issuer 的数字签名以及见证更新或零知识证明生成所需的附加信息。

{
  "@context": [...],
  "id": "http://dmv.example.gov/credentials/DL2024-789456",
  "type": ["VerifiableCredential", "DriverLicenseCredential"],
  "issuer": {"id": "did:web:dmv.example.gov"},
  "issuanceDate": "2024-03-15T10:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "licenseNumber": "DL789456",
    "licenseClass": "C"
  },
  "credentialStatus": {
    "id": "https://dmv.example.gov/revocation-lists/2024#45678",
    "type": "BachelorOfScience",
    "revocationListIndex": "45678",
    "revocationListCredential": "..."
  },
  "proof": {
    "type": "Ed25519Signature2020",
    ...
  }
}

VP（可验证陈述）：VC 的集合或派生证明,是对一张或多张 VC 的封装展示，支持选择性披露。VP 的选择性披露特性与撤销机制之间存在张力——许多撤销机制在状态检查时会暴露稳定标识符，使 Verifier 能够跨多次陈述进行关联，损害 VP 的隐私性。

VDR（可验证数据注册表）：存储 DID 文档、公钥、凭证 Schema、撤销状态数据与治理记录的共享防篡改存储库。实践中通常采用混合架构：区块链作为不可变锚点处理关键或低频更新，数据库或文件系统层（如 IPFS）处理频繁变化的撤销列表，以平衡信任与性能。

存储类型 代表技术 优点 缺点
区块链 Ethereum, Hyperledger Indy, Bitcoin 去中心化、防篡改 吞吐量低、更新成本高
数据库 传统关系型/NoSQL 高吞吐、低延迟 需要严格访问控制
文件系统 IPFS, Git 版本控制、去中心化分发 同步复杂
混合架构 区块链 + 数据库 平衡信任与性能 设计复杂

实践中：区块链作为不可变锚点存储关键/低频更新（如公钥、DID），数据库或文件层处理高频变化的撤销列表。

SSI 工作流中的撤销

颁发阶段：

  • 持有者创建DID并将DID文档发布到VDR；生成的密钥和标识符随后支持见证更新和不可撤销证明。然后持有者请求凭证。
  • 颁发者执行适合上下文的身份检查，并保留足够的详细信息，以便在凭证受到质疑时支持未来的审核。发行人将 VC 与所需的声明和元数据组装在一起，对其进行签名，然后将其返回给持有者。
  • 在同一步骤中，发行人启用撤销方法（通常是列表或累加器），发布相关状态，并向持有者提供证明当前未撤销状态所需的任何证人或证明材料。

验证阶段：

  • 在凭证验证的工作流程中，验证者要求持有者提供特定的凭证或证明。持有者选择满足验证者要求的适当凭证并用它们制作 VP。、
  • 由于这一部分，撤销检查变得更加复杂——持有者可能需要在其 VP 中包含非撤销证明。他们也不得损害隐私。
  • 撤销状态检查须在每次 VP 验证时执行，同时维护隐私并避免 “calling home” 问题（即每次验证都联系 Issuer，使 Issuer 获知 Holder 的凭证使用行为）。Holder 可能需要在 VP 中附加非撤销证明，Verifier 则需对此进行密码学验证。

撤销在 SSI 中的挑战来源

传统 PKI 的 CRL 和 OCSP 与 SSI 的三条核心原则存在根本冲突：

  • 避免持续的三方交互：OCSP 每次验证都须实时联系 CA，直接违反颁发后独立性原则
  • 强隐私保障：CRL 暴露完整撤销列表；OCSP 使 CA 获知验证双方的身份与时间信息
  • 防止单点故障：中心化撤销服务一旦不可用，全网验证即告中断

SSI 因此需要同时满足去中心化、保密性、可扩展性与离线可验证性的全新撤销机制。

三、典型用例

VC 撤销场景

员工凭证撤销：员工离职后，其工作证明 VC 必须立即失效，防止其继续以前员工身份访问公司资源。与传统系统不同，SSI 中员工独立持有凭证，验证者不能直接问发行者（这违反隐私原则），所以需要一种不依赖发行者实时查询的撤销机制。

医师执照暂停：医生执照可能因法律原因被暂时吊销。撤销系统必须：

  • 支持临时或永久撤销
  • 即使患者离线也能验证执照状态

学位证书欺诈：发现学生用伪造文件获取学位后，大学必须撤销相应凭证。同时：

  • 保护合法持有者的个人信息
  • 抵御关联攻击（防止推断某人同时持有多张凭证）

DID 注销场景

私钥泄露（EU 数字新冠证书事件，2021年）：黑客泄露 EU 数字新冠证书签名私钥，导致可为任意主体生成通过官方验证的假健康码。当局撤销泄露密钥后，所有依赖该密钥颁发的证书即刻失效。该事件展示了 DID 私钥泄露后须立即注销对应 DID 的实际场景。

设备丢失（移动驾照，mDL）：DID 通常与存储在设备上的密钥绑定。手机丢失时，现代 mDL 系统允许 Issuer 或用户远程注销关联的数字身份，使其无法再被任何人使用。该能力已成为数字身份部署的标准安全实践。

did:web 域名到期劫持：did:web 依赖互联网域名托管 DID Document。域名注册到期后，第三方可购买该域名并发布自定义的 DID Document，完全劫持原来的 DID 控制权。社区已意识到此风险，并催生了 did:webs 等内嵌密码学证明的新方法以防止域名易主后的控制权丧失。

基础设施关闭（Sovrin MainNet，2024年）：Sovrin 基金会因可持续性与监管挑战，宣布于 2025 年 3 月前关闭 MainNet 账本。此后，所有基于 did:sov 的 DID 将无法解析或更新，等同于批量注销。使用这些 DID 的组织须迁移至其他 DID 方法，该事件揭示了 DID 可移植性规划的重要性。

四、撤销机制分类详解

VC 撤销机制
├── A. 列表式（List-based）
│   ├── A1. 证书撤销列表（CRL）/ 撤销信息列表
│   ├── A2. 比特串状态列表（Bitstring Status List, BSL）
│   └── A3. 在线状态协议（OSP/OCSP）
├── B. 密码学累加器（Cryptographic Accumulators）
│   ├── B1. RSA 累加器
│   ├── B2. 双线性映射累加器
│   ├── B3. 默克尔树累加器
│   └── B4. 见证值管理技术
├── C. 正向确认式（Positive-Confirmation）
│   ├── C1. 短期凭证（Short-lived credentials）
│   ├── C2. 信任锚/允许列表分发
│   └── C3. 关联有效性 VC（LVVC）
└── D. 治理感知式（Governance-aware）
    ├── D1. 层级管理
    ├── D2. 联合撤销
    └── D3. 自适应策略控制

DID 注销
└── E. DID 层注销与恢复
    ├── E1. 控制者主动注销
    ├── E2. 行政撤销
    └── E3. 密钥妥协与紧急响应

A. 基于列表的撤销（List-Based Revocation）

A1. 证书撤销列表（CRL）及 SSI 变体

Issuer 维护被撤销凭证标识符（或哈希）的签名列表，定期推送至 VDR，Verifier 下载后比对。在 SSI 语境中，列表存储凭证标识符或哈希，而非传统的证书序列号，存储位置为 VDR 而非中心化服务器。

主要限制：公开列表会暴露 Issuer 的撤销频率及凭证类型分布；列表大小随系统规模线性增长；时效性存在缺陷——Issuer 即时记录撤销，但 Verifier 仅在下次拉取时才获知变更。

A2. 位字符串状态列表（Bitstring Status List, BSL）

BSL（压缩前）：0 0 0 0 0 1 0 0 0 1 0 0 ...
                ↑             ↑
              VC 0           VC 5（已撤销）

W3C 推荐的主流方案。每张凭证在颁发时分配固定索引位置，BSL 为压缩位数组，撤销时将对应 bit 从 0 翻转为 1。Issuer 对整个位字符串签名并重新发布至 VDR，Verifier 检查凭证索引处的单个 bit，时间复杂度 O(1)。

压缩技术：BSL 使用 GZIP 减少存储与传输开销。GZIP 通过 LZ77 风格的子串去重检测重复字节模式，再应用霍夫曼编码对剩余符号进行熵编码。撤销率低时（大量 bit 为 0），压缩比极高。

隐私问题：跨多次陈述复用同一状态索引可能导致可关联性——Verifier 可通过索引追踪同一 Holder 的使用行为；索引管理不当可能导致模糊性

BSL 可配合 CDN 分发，支持高效的离线验证路径。微软 Entra Verified ID 采用了该方案。

A3. 在线状态协议（Online Status Protocol, OSP）

类比传统 PKI 的 OCSP，Verifier 实时向状态服务查询特定凭证的当前状态，服务返回状态、时间戳与密码学证明。部分协议采用零知识证明或盲签名等隐私保护扩展。

根本缺陷为calling home问题：每次查询使状态服务或 Issuer 获知验证双方的身份与时间信息，严重违反 SSI 隐私原则，并引入对在线服务可用性的依赖，可能开启监控与审查。该方案仅适用于高安全性场景下隐私代价可接受的情形。

OpenAttestation 框架采用 OSP 进行验证，但其状态信息服务是中心化的，网络故障或服务中断会中断验证流程。

B. 密码学累加器（Cryptographic Accumulators）

密码学累加器用紧凑值表示集合，支持高效的成员关系证明而不暴露其他成员信息。在 SSI 撤销中，累加器维护有效或已撤销凭证标识符的集合，提供优于列表式方案的隐私特性。

基本机制

工作流程：

  1. 初始化：Issuer 基于强 RSA 假设或双线性配对初始化累加器
  2. 累积：颁发凭证时将凭证标识符加入累加器，更新累加器值
  3. 见证生成：为每张凭证生成见证值 $w_i$——证明该凭证包含于集合的密码学证明，不暴露其他成员信息
  4. 撤销更新：撤销凭证时将其从有效集合移除（或加入撤销集合），更新累加器值；未撤销凭证的见证值通常须随之更新
  5. 验证：Holder 在 VP 中提供见证值，Verifier 用当前累加器值验证成员关系（或非成员关系），无需查看完整撤销列表或联系 Issuer

两种类型：正向累加器（Positive Accumulator）累积有效凭证集合，见证值证明"属于有效集合"；通用累加器（Universal Accumulator）同时支持成员证明与非成员证明。

B1. RSA 累加器

经典构造（Benaloh & de Mare, 1994）：

在 RSA 模数 $n = pq$（安全素数）、生成元 $g \in QR_n$ 下，对集合 $S = {x_1, ..., x_k}$ 的素数编码元素，累加器值为：

$$A_S = g^{\prod_{x \in S} x} \mod n$$

元素 $x$ 的成员见证：$w_x = g^{\prod_{y \in S \setminus {x}} y} \mod n$，验证：$w_x^x \equiv A_S \mod n$

安全性基于强 RSA 假设，但传统构造要求所有累积元素为素数，导致代价高昂的哈希到素数操作，在处理大型数字对象时尤为突出。

最新无素数要求的 RSA 累加器（Kemmoe & Lysyanskaya, CCS 2024）：

使用随机预言机 $H$ 将输入映射至大奇数集合 $\text{Odds}(2^{\ell-1}, 2^\ell - 1)$，累加器定义为 $A_S = g^{\prod_{x \in S} H(x)} \mod n$。随机大奇数几乎必然有大素因子，从而避免了除数泄露漏洞，同时维持方案的可靠性。

该方案的关键创新在于见证更新机制：当元素 $y$ 被撤销时，协议维护 $H(x)$ 与所有已撤销元素哈希值之间的 GCD 信息，利用 Shamir 技巧在 $H(x)$ 与 $H(y)$ 非互质时仍能正确计算更新见证——此为与此前方案相比的核心突破（此前构造均要求哈希结果互质）。

该方案还结合 Wesolowski 的 VDF 处理任意奇数，支持通过指数证明（Proof of Exponentiation）生成批量成员证明，同时具备正向累加器与通用累加器特性，适合 WebPKI 场景中计算能力有限的 CA。

B2. 双线性配对累加器（Bilinear Accumulators）

基本构造：

参数：$G_1, G_2$ 为素阶 $q$ 的循环群，$g_1 \in G_1, g_2 \in G_2$ 为生成元，$e: G_1 \times G_2 \to G_T$ 为双线性配对，$\alpha \in \mathbb{Z}_q$ 为秘密陷门值。

对集合 $S = {x_1, ..., x_n}$，累加器为 $V = g_1^{\prod_{x \in S}(x+\alpha)}$；$y \in S$ 的见证 $w_y = g_1^{\prod_{x \in S, x \neq y}(x+\alpha)}$；验证：$e(w_y, g_2^{y+\alpha}) \stackrel{?}{=} e(V, g_2)$。

方案演进：

  • Nguyen（2005）：首次提出双线性累加器，证明代数可行性，但每次更新须重新计算累加器值并刷新所有未撤销成员的见证，计算成本随集合大小增长；缺乏高效的删除与批量撤销机制

  • Karantaidou & Baldimtsi（CSF 2021）：构造正向与通用累加器，引入常数大小的成员/非成员证明及零知识变体，解决了此前方案缺乏高效非成员证明、见证大小或验证成本随撤销数量增长的问题，支持高效动态更新

  • Vitto & Biryukov（RSA 2022）：提出基于多项式的批量更新机制。设 $A$ 为新增元素集，$D$ 为撤销集，定义 $A(X) = \prod_{a \in A}(X-a)$，$D(X) = \prod_{d \in D}(X-d)$，新累加器 $V' = \frac{A(-\alpha)}{D(-\alpha)} \cdot V$，见证对应批量更新。更新可委托给不可信服务器执行（结果仍可公开验证），安全性基于广义 $t$-强 Diffie-Hellman 假设

  • ALLOSAUR（Jaques et al., AsiaCCS 2024）：专注于见证更新过程中的隐私保护。传统方案中见证更新须由权威方或外部服务执行，可能泄露敏感信息。ALLOSAUR 使用安全多方计算（MPC）：多个独立方联合执行更新，确保无单一方获取 Holder 的更新见证，且见证更新匿名且不可关联至特定 Holder。协议复杂度 $O(\sqrt{m})$（$m$ 为撤销数量），实践中处理 1000 次撤销耗时不超过 500ms，通信开销仅 16KB

B3. Merkle Tree 累加器

工作原理：

  1. 每个被撤销的凭证标识符被哈希后作为叶节点
  2. 父节点 = Hash(左子 || 右子)，递归向上
  3. 根哈希值作为累加器
  4. 某元素的见证值 = 从叶到根路径上所有兄弟节点的哈希集合
				h0（累加器根）
             /              \
           h1                h2
          /    \            /    \
        h3      h4        h5      h6
        |       |         |       |
      H(M1)   H(M2)     H(M3)   H(M4)

M2 的见证值 = {h3, h2}，验证：重建路径计算根哈希，与 h0 比较。

特点：

  • 只需哈希函数，无需配对运算，极度轻量
  • 证明大小为 O(log n)，适合区块链和资源受限 IoT 环境
  • 标准默克尔树擅长成员证明，非成员证明需要额外策略

隐私增强的近期工作：

  • Prevoke（IEEE Blockchain 2024）：可配置的隐私保护撤销，支持对披露策略的细粒度控制
  • Sitouah et al.（ICBC 2024）：通过随机哈希值构造不可追踪的 Merkle Tree 累加器，防止跨不同验证的非撤销证明之间的关联
  • 零知识友好 Merkle Tree：使用 ZK 友好哈希函数与电路设计，使用户无需暴露树中位置即可证明非撤销状态

B4. 累加器更新与见证管理

动态累加器面临的核心挑战：每次撤销都会改变公开累加器值，使所有现有持有者的见证值失效。

四种管理策略：

策略 说明 优点 缺点
广播更新 发行者公开广播更新数据，持有者自行计算新见证值 无需交互，保护隐私 持有者需处理所有历史更新
见证值更新服务 专用服务为持有者计算更新 适合资源受限设备 可观察更新模式，存在隐私风险
批量更新 将多次撤销合并处理 降低通信和计算开销 牺牲新鲜度
聚合证明 将多个见证值聚合成单个证明 降低验证成本 成员变化时更新复杂

C. 正向确认模型（Positive-Confirmation Approaches）

传统撤销（CRL/累加器）是负向确认——默认有效，撤销时标记为无效。
正向确认则相反——只接受明确声明为有效的凭证，缺乏确认即视为撤销。

C1. 短期凭证（Short-lived Re-issuance）

原理：给凭证设置极短的有效期（如几小时或几天），到期自动失效，发行者定期重新颁发。

类比：好比"当天有效的通行证"——每天早上重新签发，失效就不续签。

代表标准：RFC 8739 ACME-STAR（自动证书管理环境中的短期、自动续签证书）

优点：

  • 无需撤销注册表
  • 支持离线验证（只需检查过期时间）
  • 自然对齐密钥/策略轮换

缺点：

  • 频繁更新带来发行者负担
  • 无法即时处理紧急情况（如密钥泄露）——仍需紧急撤销后备机制

C2. 信任锚/允许列表分发

原理：验证者只接受当前允许列表上的发行者/密钥，而不是执行全局负向检查。

代表应用：ISO/IEC 18013-5 mDL（移动驾照）生态系统，AAMVA 的 DTS/VICAL 分发当前发行者公钥，验证者依赖"谁现在是可信的"而非检查谁被撤销了。

C3. 关联有效性 VC（Linked Validity VC, LVVC）

原理：将一张 VC 拆分为两部分：

  • 内容 VC：包含实际声明（不经常变化）
  • 有效性 VC（LVVC）：只包含有效期/状态信息，由发行者频繁刷新

验证者同时要求两张 VC；如果发行者停止发出 LVVC，缺乏正向确认即等同于撤销。

持有者钱包：
  ┌────────────────────────────────┐
  │ 内容 VC（长期有效，含实际属性） │
  └────────────────────────────────┘
  ┌────────────────────────────────┐
  │ LVVC（短期有效，定期更新）      │  ← 发行者每 N 天刷新
  └────────────────────────────────┘

优点：

  • 减少内容 VC 的暴露频率
  • 验证者无需联系发行者（因为总有新的 LVVC）
  • 已有实际部署（Procivis 等）

缺点：

  • 持有者需要定期联系发行者获取新 LVVC（与"发行者独立性"原则有轻微张力）
  • 刷新模式可能导致时序关联攻击（需要随机化刷新窗口等缓解措施）

D. 治理感知与自适应撤销（Governance-Aware and Adaptive Revocation）

该类方案关注撤销的组织、政策与监管层面，而非密码学机制本身。

层级管理（Hierarchical Management）：在大型组织中，各级管理者在可控范围内拥有撤销权限，全局管理员控制全局范围。优势在于精细管理，挑战在于防止未授权的权限提升，以及建立有效的审计机制。

联邦撤销（Federated Revocation）：多组织环境中，撤销决策须经跨组织的司法管辖协调与共识机制。须考虑与 SSI 现有方法的兼容性。

可配置/自适应策略控制（Adaptive Policy-Based Control）：可配置系统允许管理员设置隐私级别、新鲜度要求与传输格式参数；自适应系统则根据当前网络条件和安全威胁自动调整撤销策略，确保系统韧性与跨格式互操作性。

E. DID 注销（DID Deactivation）

DID 注销与 VC 撤销是两个正交的层次，须独立处理以避免"过度撤销"。

W3C 规范的信号机制：DID 注销通过 DID 解析元数据（didDocumentMetadata.deactivated = true）表示，而非修改 DID Document 内部字段。DID Core 规范将注销的存在性、授权方式与效果委托给具体 DID 方法规范及其关联治理框架。

控制者发起的注销（Owner-Initiated Deactivation）：DID 控制者使用专用恢复密钥授权 deactivate 操作。成功后，解析器返回 deactivated = true，方法规则不再处理该 DID 的任何后续操作（实质上不可逆）。Sidetree/ION 方法明确区分 recover 与 deactivate 操作，deactivate 执行后所有后续操作均被忽略。

不同 DID 方法的注销实现存在差异：追加式账本方法记录墓碑/Deactivate 条目；did:web 通过使 did.json 不可访问（如删除）来表示注销；链下方法依赖解析器元数据或代理中介状态。

行政撤销（Administrative Revocation）：部分 SSI 环境中，网络管理员或监管机构在满足特定条件（政策违规、法律命令、安全事件）时拥有有限的 DID 注销权力。此类能力须在规则规范与治理框架中明确界定，以维持与 SSI 用户控制原则的一致性。Sierra Leone 的 Kiva/Indy 项目展示了基于行政措施（而非技术手段）进行治理设计的实践。

密钥泄露与应急响应（Key Compromise and Emergency Procedures）：私钥泄露时，优先选择密钥恢复或轮换（保持标识符连续性），仅在恢复不可行或风险评估要求退休时才执行注销。支持机制包括：专用恢复密钥（区别于更新密钥）、多签名或社会恢复机制。推荐分阶段响应：将 DID 标记为高风险 → 尝试恢复/轮换 → 确认泄露后执行完全注销。

与 VC 撤销的关系：DID 注销影响该标识符下的所有密钥与服务，间接影响依赖该 DID 的 VC 验证流程。但凭证撤销状态由 VC 状态列表或累加器管理，与 DID 注销正交，系统应独立处理两个层次以避免过度撤销。

五、隐私分析

隐私泄露的三类场景

Manimaran et al. 在研究 SSI 环境中通过 Issuer 查询撤销信息时，识别了三类具体隐私泄露场景（Prevoke）：

场景一：Holder-Verifier 关联泄露：若 Verifier 向 Issuer 查询撤销状态，Issuer 即可获知验证双方的身份与时间信息。典型案例：雇主 A（Issuer）为员工 X（Holder）颁发工作凭证，员工 X 在雇主 B（Verifier）处面试时，雇主 B 向雇主 A 查询凭证状态，使雇主 A 获知员工 X 的求职行为。

场景二：Holder 状态与唯一标识泄露：任何第三方均可向 Issuer 查询特定 Holder 的 VC 状态，可用于推断其就业状况等敏感信息。

场景三：撤销率泄露：Issuer 的批量撤销率变化可能揭示商业敏感信息，如员工离职率或监管调查情况。

各利益相关方的隐私风险

  • 传统列表式（CRL/OCSP）：最差。凭证标识符或其确定性哈希值在查询时暴露，启用跨验证者的关联攻击，甚至可能通过字典攻击重建使用模式。
  • BSL：通过固定大小压缩位数组改善，但状态索引复用问题依然存在。
  • 累加器 + 零知识证明：最佳隐私保护，持有者可在不暴露身份的情况下证明"未被撤销"。
  • LVVC：通过解耦内容与状态，减少内容暴露；刷新模式需随机化以防时序关联。

六、可扩展性与性能比较

论文 Table 2 对各方案可扩展性与性能的系统比较：

方案 典型存储 验证时间 更新频率 网络开销
CRL / OCSP 线性增长（WebPKI 达数十 MB） <10ms（缓存/Stapled 状态） 每次撤销或缓存过期时 无 Stapling 时高；频繁在线查询
BSL 每人群分段常数大小（KB 级） <50ms（bit 检查 + 签名验证） 周期性批量更新（日/周） 低（CDN/缓存分发；CRLite 式推送可行）
累加器（RSA/配对基） 常数大小公开累加器 + 每 Holder 见证（数百字节至 KB 级） 50–200ms（模指数/双线性配对） 频繁见证刷新（每次撤销事件） 中等（见证更新随撤销率增长）
ZKP 选择性披露（BBS+/Groth16/PLONK/STARKs） 每次陈述的证明制品（数十 KB） 200–800ms（移动端，含预计算/批处理） 陈述时；Issuer 更新与证明解耦 中-高（制品比列表大，但离线友好）
Hyperledger Indy / AnonCreds 尾文件可能达 GB 级（无分区时） 取决于证明类型；含缓存时实践中亚秒级 撤销事件时注册表更新 中等（须仔细分片/CDN 策略处理尾文件）

结论：没有哪种方法在所有维度都占优。选择时需根据具体场景权衡：

  • 需要高性能离线验证 → BSL
  • 需要强隐私/不可关联 → 累加器 + ZKP
  • 需要简单部署 → 短期凭证（LVVC）
  • IoT/资源受限 → 默克尔树累加器

七、开放挑战与未来方向

技术挑战

1. 隐私与可问责性的平衡

这是最核心的张力。SSI 强调隐私和用户控制，但现实中存在合法的追踪、审计和监管合规需求：

  • AML（反洗钱）法规要求金融机构维护身份验证详细记录
  • 执法机构可能需要调查凭证滥用
  • 组织需要证明合规

研究方向：

  • 选择性审计（特定凭证可审计，其余保留隐私）
  • 时延透明（审计信息在指定延迟后可用）
  • 基于门限的披露（只在特定条件满足时披露审计信息）
  • 密码学审计（使用 ZKP 验证而不完全披露）

2. 离线验证的复杂性

在无网络连接场景（移动、IoT、紧急情况）中，如何可靠地验证撤销状态？

挑战：

  • 新鲜度 vs 存储成本的权衡
  • 多个离线验证者需要一致的撤销视图
  • 资源受限设备无法存储大量撤销信息
  • 本地缓存信息可能过时

研究方向：

  • 优化缓存策略（平衡存储与新鲜度）
  • 基于使用模式的预测性预加载
  • 优雅降级的混合在线/离线验证
  • 适用于间歇性连接的分布式共识机制

3. 密钥管理与恢复

SSI 用户独立管理密钥，没有中央机构可以重置——这与传统系统的关键区别：

场景 传统系统 SSI
私钥丢失 联系中央机构重置 无法证明凭证有效性 ❌
密钥被盗 管理员立即锁定 难以即时检测，去中心化限制自动检测
长寿命凭证 定期更新协议 算法可能在凭证过期前就过时

解决方案方向：

  • 社交恢复（将部分恢复权限委托给信任的朋友/机构）
  • HSM/TEE 硬件保护
  • 门限密码学（密钥分片，需要 k/n 份才能重建）
  • 自动化密钥轮换协议（支持前向保密）

4. 后量子密码（PQC）就绪性

量子计算机运行 Shor 算法可以在多项式时间内破解 RSA、ECC、离散对数等当前主流密码算法——这将直接威胁现有所有基于这些算法的撤销机制。

当前 SSI 中受威胁的组件：

  • RSA 累加器
  • 双线性配对（基于椭圆曲线）
  • 现有的 ZKP 系统（如 Groth16、PLONK）

候选替代方案：

  • STARKs：无需可信设置，趋向后量子安全假设
  • 格密码学（Lattice-based）：正在开发的格密码学累加器和零知识证明
  • 代码基密码学（Code-based）

额外挑战：密码学迁移问题——系统需要在新旧算法之间保持向后兼容性，确保旧凭证在算法过渡期间仍可验证。

5. IoT 与边缘计算集成

IoT 设备的特殊约束：

  • 计算、存储、带宽均受限
  • 设备数量达百万级，且高度异构
  • 物理可接触性导致硬件攻击风险高

研究方向：

  • 专为资源受限设备设计的轻量级撤销机制
  • 层级撤销系统（将复杂操作委托给边缘网关）
  • 安全硬件方案

跨学科挑战

标准化与互操作性

当前状况：

  • W3C 的 DID 和 VC 标准提供数据模型基础
  • 但各实现在状态传播方法、状态列表格式、验证者操作假设等方面存在分歧
  • 导致跨系统凭证验证困难，阻碍 SSI 大规模采用

监管合规

主要矛盾：

  • GDPR 被遗忘权 vs 区块链不可篡改性：区块链上的撤销记录与删除个人数据的权利直接冲突
  • 数据最小化原则要求验证者只能访问必要信息
  • 金融监管（AML/KYC）要求详细审计记录
  • 跨境数据传输触发额外法律要求

八、相关综述比较

论文 Table 3 系统比较了此前 8 篇 SSI/DID 相关综述对撤销机制的处理深度：

综述 对撤销的处理
Soltani et al. (2021) 提到 VDR 可持有撤销信息，无技术规范或协议细节
Čučko & Turkanović (2021) 宏观视角梳理 SSI 研究生态，撤销仅作为其中一个位置
Bai et al. (2022) 提到链上证书撤销与钱包密钥撤销，无具体方法
Ernstberger et al. (2023) 将撤销与 DID 注销认定为基本功能，但不提供专项分析
Tan et al. (2023) 强调撤销是核心问题，聚焦去中心化与离线验证需求，无方法细节
Krul et al. (2024) 列出相关威胁与部分规范参考，无方法细节
Mazzocca et al. (2025) 引入 W3C Revocation List 2020，认为撤销是"相对欠研究的领域"
Misra et al. (2025) 无撤销相关内容

上述综述均未对 SSI 撤销机制提供系统性技术分类与比较，本文填补了这一空白。

九、综合分类表（Table 1 精华）

顶级类别 子类别 核心技术 主要优势 主要挑战
A. 列表式 CRL/RIL 哈希撤销标识符；签名时间戳列表 设计简单，兼容性广 列表增长；标识符关联
BSL W3C 状态列表；GZIP 压缩 O(1) 查询；离线友好；可扩展 索引关联性；发行者更新负担
在线状态协议 OCSP 风格查询；完整性证明 实时准确 “打电话回家"隐私问题
B. 密码学累加器 RSA 累加器 素数代表动态累加器；无需哈希到素数的变体 常数大小证明；强隐私 见证值更新复杂性
双线性映射 多项式批量更新；通用成员/非成员证明 快速批量更新；ZK 集成友好 配对计算开销；可信设置问题
默克尔树 稀疏默克尔树；ZK 友好；随机化叶节点 轻量哈希；区块链原生 非成员证明复杂性
见证值管理 广播更新；匿名更新服务；聚合证明 设备灵活性；减少通信 同步成本；延迟调优
C. 正向确认 短期凭证 自动短期刷新（ACME-STAR） 无需撤销注册表；离线验证友好 频繁刷新 → 在线依赖；难以快速撤销
允许列表分发 mDL 的信任锚供应 离线验证友好 难以快速撤销发行者
LVVC 独立有效性令牌；不续签 = 撤销 减少关联性；更新数据量小 持有者需定期联系发行者
D. 治理感知 层级管理 本地 vs 全局范围；委托规则 适合大型组织；跨生态互操作 防滥用；审计要求
联合撤销 多司法管辖共识；跨账本桥接 跨生态互操作 治理复杂性；延迟
自适应策略 情境感知规则；威胁驱动撤销 对异构性的韧性 系统复杂性高
E. DID 注销 控制者主动注销 恢复密钥禁用控制 强用户自主性 需与 VC 撤销同步
行政撤销 管理员或监管者干预 紧急处理 过度中心化风险
密钥妥协响应 多签恢复；基于事件的撤销信号 防止标识符劫持 永久丢失风险

十、结论

论文的核心结论是：SSI 中没有单一撤销方案能同时满足所有需求，每种方案均有不同的权衡关系。

列表式方案设计简单、部署广泛，但可能因可关联状态检查损害隐私；带零知识证明的累加器方案增强隐私并减少网络开销，代价是更高的计算复杂度；正向确认策略（短期凭证或 LVVC）避免持续状态检查，但引入频繁的凭证刷新需求；DID 注销支持全局凭证失效，但带来互操作性与治理挑战。

若干根本性技术挑战仍未解决：隐私保护的离线验证、安全的密钥管理与恢复、后量子就绪性、IoT 等资源受限环境的支持，以及异构 SSI 生态系统间的互操作性。此外，法律与监管需求（可审计性、法律责任、数据保护）进一步复杂化了撤销系统的设计空间。

参考

  • 论文原文：IEEE Access 2026
  • W3C Bitstring Status List v1.0：https://www.w3.org/TR/vc-bitstring-status-list/
  • W3C VC Data Model v2.0：https://www.w3.org/TR/vc-data-model-2.0/
  • Hyperledger AnonCreds Spec：https://hyperledger.github.io/anoncreds-spec/
  • EVOKE（IoT VC 撤销，USENIX Security 2024）：Mazzocca et al.
  • ALLOSAUR（AsiaCCS 2024）：Jaques et al.
  • CRLite（IEEE S&P 2017）：Larisch et al.
  • Prevoke（IEEE Blockchain 2024）：Manimaran et al.
  • Kemmoe & Lysyanskaya RSA 累加器（CCS 2024）