摘要

  • W3C 可验证凭证工作组在 9 月 24 日发布独立的 Verifiable Credentials Data Model Threat Model v2.1 首版 Group Note 草案；9 月 20 日的数据模型工作草案附录已先列出简要风险。
  • 新文件将 25 项威胁分为规范目标、实现、部署、外部与依赖五组，补上情景、建议回应和受影响组件；这些分组不是安全评分，更不是控制已经运行的证明。
  • 真签名、有效状态可能与错误的身份核实、不安全的内容呈现或不合用途的采信同时存在。文件仍是未获 W3C 背书的草案。

一张证书写着某人的姓名，签名是真的，撤销状态也正常。它仍可能是发给了冒名者：签发机构最初核对身份时受了骗，后来所有密码学检查都只能确认“这确实是该机构发出的内容”，无法倒过来重做当时的身份审查。W3C 新威胁模型的 T25 说的正是这一段断层。签发者选择与凭证用途风险相称的身份核实强度，核验方则要决定这个保证水平能不能支撑自己将要作出的判断。

9 月 24 日的新闻，是工作组把威胁分析作为独立 Group Note Draft 发布。不能把它写成 25 项风险首次问世：四天前的 Verifiable Credentials Data Model v2.1 Working Draft 已在非规范性附录 A 列出五类威胁的简述。独立 Note 的新增价值在于逐项展开攻击路径、应对方法和所涉流程，让责任交接比短清单更可追问。它不因篇幅变长就自动成为可执行保证。

清单里有两项“目标威胁”、七项实现威胁、十一项部署威胁、四项外部威胁和一项依赖威胁。这个结构提示风险落在不同控制面，但不能拿十一与二的数量推算事故概率或宣称部署风险更严重。尤其值得注意的是，T25 虽被列入目标威胁，细节却明说数据模型自身不能强制签发者如何核实身份。列在标准打算处理的栏目，并不等于现实中的签发流程已有合格控制。文档的词汇表也明确承认部分条目只是待扩充的起始定义。

再看 T1：被保护的声明若被改动，验证安全机制可以发现；如果攻击者把证明整段剥除，密码学无从验证一个根本不存在的证明。需要签发者背书的场景，核验方必须在自己的规则里要求相应证明。无证明凭证并非一概非法，规范允许自述或中间存储用途；不能做的是将其当作已经由签发者认证的断言。这里需要的是采信政策，而不只是验签程序。

软件侧还有另一条线。T2 讨论凭证内可能携带可执行标记：签名保护了内容的完整性，却没有保证钱包或核验服务展示内容时不会执行恶意代码。输出编码、隔离呈现或避免此类内容，属于实现选择。T24 则发生在业务决定处：签名和状态都通过，不足以说明一份自述材料适合充当专业诊断或其他特定依据。核验方还得判断来源、声明性质与所需用途是否相配。这篇报道不重复另一个 Bitstring Status List v1.1 草案里关于短状态指针及 statusPurpose 的争议。

一个可操作的做法，是在组织内部为相关威胁记下负责主体、实际决策点、选用的控制和运行证据。这个“责任账”只是 Daniel Kade 的编辑性建议，不是 W3C 指定格式。它能把“规范已经提到风险”与“本系统有人落实缓解措施”分开。签发者、钱包提供者、核验方彼此独立时，后一问比列出更多术语更难，也更重要。

文件权威也要分清：数据模型 v2.0 在 2025 年成为 W3C Recommendation；2026 年的 v2.1 数据模型仍是 Working Draft，这份威胁模型则是 Note 轨道上未获背书的 Group Note Draft。它没有给任何具名产品颁发证明，也未记录现实事故或法律责任。新文件真正提供的是一张可供追问的图：每一项风险抵达实际决策前，究竟由谁承担控制，证据又留在哪里？

资料来源