摘要

  • W3C 于 9 月 24 日发布 Bitstring Status List v1.1 首个公开工作草案；2025 年发布的 v1.0 仍是正式 Recommendation。
  • 新增的紧凑状态条目只携带基础 URL 与 32 位索引；完整查询中的状态用途由验证方在转换时提供。
  • 列表容量、凭证字段变少，都不能单独证明实际人群隐私、列表新鲜度或状态发布权威。

在一张数字凭证上省掉几个字段，看似只是编码问题；在验证现场，被省掉的可能是问题本身。W3C 可验证凭证工作组 9 月 24 日发布的 Bitstring Status List v1.1 首个公开工作草案，新增 TerseBitstringStatusListEntry：凭证里的引用压缩为一个基础 URL 和一个索引，验证程序再把它还原为可查询共享状态列表的完整条目。还原需要知道究竟要查撤销、暂停，还是另一个用途，而这个用途不在紧凑条目里。

先分清标准的时间线。共享位串状态列表并非此次首次提出；Bitstring Status List v1.0 已在 2025 年 5 月成为 W3C Recommendation。它试图避免每张凭证各自对应一次可被追踪的状态查询，也允许凭证签发者与状态列表签发者不是同一主体。v1.1 当前只是面向意见反馈的工作草案，不能写成已被 W3C 成员背书的新规范，更不能据此推定任何机构已经启用新格式。

草案的增量有清楚的算式。紧凑索引需能以 32 位无符号整数表示；转换规则规定每份列表有 2²⁶ 个位置、列表编号空间为 2⁶。验证方用整数除法得出列表编号，用余数得出列表内位置，再把基础 URL、状态用途、列表编号拼成待取的地址。这说明的是寻址规则，并不意味着现实中已有 64 份列表上线。

关键治理分界在用途。草案明确说，紧凑条目不表达 statusPurpose，转换算法由验证方提供该值。通常先对已签名的紧凑条目验签，再执行转换。因而签名能够固定凭证里的指针，却不会替验证方决定该查哪一种状态。如果两个核验系统对同一凭证提出不同的问题，单靠相同的 32 位索引不能把它们的决策自动统一。

取到列表也不是终点。验证流程仍要求检查其证明；持有人可以随凭证提供已签名的列表，减少向发布端发起即时请求，但验证方可能要求更新的版本。可选的 ttl 只提示何时刷新，不能延长列表本身的有效期。草案还提醒：列表留有大量空位，不等于背后真有大量持有人；真实发行量过小，群体隐私仍可能落空。

资料来源