摘要

  • 2024 年生效、现已延长至 2026 年 10 月 28 日的 DID 工作组章程，把 DID Resolution 纳入 Recommendation Track。8 月的工作并不处于授权真空。
  • 8 月 6 日发布的 Candidate Recommendation Snapshot 同时是 Patent Review Draft，触发了截至 10 月 5 日的专利排除机会，并提出逐项功能的实现证据要求；它不是最终 Recommendation，也不代表 W3C 背书。
  • W3C 于 8 月 10 日启动延续性再授权的公开细化。可是截至 8 月 30 日，公开草案及其 8 月 27 日仓库头仍把 DID Resolution 写成 Working Draft，称最新发布为 7 月 10 日，并指向 2024 年的旧 Exclusion Draft。
  • W3C 官方发布历史又在 8 月 28 日增加了 Candidate Recommendation Draft。它是更新的工作文本，但不会因为日期更新，就自动取代 8 月 6 日 Snapshot 的专利参照功能。
  • 在 Advisory Committee 审议之前，应以轻量交接记录连接现行章程、最新 CR Draft、控制本轮专利状态的 Snapshot、排除期、风险功能与带时间戳的实现证据。记录只澄清状态，不新增一道许可门槛。

四只钟都准，并不等于读数不会错

第一只钟记录技术文本。W3C 的发布历史显示：8 月 6 日是 Candidate Recommendation Snapshot，8 月 28 日又发布 Candidate Recommendation Draft。若问题是“工作组当前整合到哪一版”，后者更近。

第二只钟记录专利程序。8 月 6 日 Snapshot 是 Patent Review Draft，它开启本轮 Call for Exclusions，截止日是 10 月 5 日。8 月 28 日的 Draft 并不会仅凭“更新”二字获得同一种作用。

第三只钟记录运行证据。公开实现报告写明，页面展示的测试运行发生在 3 月 27 日 14:16 UTC。这个时间说明测试矩阵的观测点，不等于技术文档的发布日期。

第四只钟记录机构权限。2024 年章程已延长到 10 月 28 日，仍然有效。下一份章程正在 refinement 阶段，尚未通过、尚未生效，开始日期也要等未来的 Call for Participation 才能确定。

任何一只钟单独拿出来都不虚假。问题出在摘要者常把“最新文本”“专利参照”“最新测试”和“当前授权”压成一个词：当前状态。这样一来，时间靠后的 CR Draft 可能被误当成本轮专利比较基准；实现方数量可能被误当成逐功能达标；尚在细化的章程又可能被说成已经接管了工作。

治理的任务不是选出一只总钟，而是保留它们之间的对应关系。

现行章程不是背景材料，而是来源链

2024 年章程做了一件具体的事：把 DID Resolution 作为新的 Recommendation-track deliverable 纳入 DID 工作组范围。章程原定在 2026 年 4 月结束，W3C 后来将它延长至 10 月 28 日。工作组页面也公开显示这个日期。

因此，8 月的 Candidate Recommendation 工作有清楚的现行权限来源。未来章程无需追认过去，也不能在尚未完成 AC Review 与 W3C Decision 时提前取代现行章程。

Strategy 第 562 号议题把这次调整定义得很窄：这是现有工作组的再授权，没有实质范围变化；原因是对 DID Resolution 形成共识比原计划花了更长时间，工作组需要更多时间。

“同一任务，多给时间”听起来最不需要复杂文件，实际却最需要交接准确。大幅变更范围会自然引来审视，延续性安排则容易让人默认所有内容都原封不动地过境。然而穿过章程边界的不只有名称，还有当前文本状态、专利参照体、尚未关闭的风险功能、测试版本和实现证据责任。

这不是“提议章程已经产生授权”的故事。恰恰相反：正因为提议仍不是授权，它才应在成为授权之前，把将要接收的状态说清楚。

Snapshot 与 Draft 同为 Candidate，却不是同一个动作

W3C 的两个术语只差一个词，很容易被中文摘要都写成“候选推荐”。Candidate Recommendation Snapshot 与 Candidate Recommendation Draft 处于同一成熟阶段，却承担不同制度功能。

8 月 6 日 Snapshot 是稳定审查点。W3C Process 把这种发布定义为 Patent Review Draft。它触发排除机会，DID 工作组的 IPR 页面因而记录了 8 月 6 日开始、10 月 5 日结束的窗口。

8 月 28 日 Draft 是持续整合面。它自己的状态说明写得很清楚：该文件吸收工作组希望放入后续 Snapshot 的变化，仍是 work in progress，可以更新、替换或废弃。W3C Process 还明确区分：CR Draft 本身不提供新的 exclusion opportunity。

所以交接单必须同时写两行：

  • 最新整合文本：2026 年 8 月 28 日 CR Draft；
  • 当前专利审查参照：2026 年 8 月 6 日 CR Snapshot；
  • 当前排除期：8 月 6 日至 10 月 5 日；
  • 下一次稳定参照：只有 W3C 真正发布新的 Snapshot 后才能记录，不能从 Draft 更新中推定。

如果只保留“最新”，日期会吞掉制度功能。如果只保留“稳定”，实现者又看不到工作组已经整合的变化。两者不是竞争版本，而是不同用途的证据。

专利记录没有消失，草案只是还没有接上

新章程草案的 DID Resolution 条目仍列出 2024 年 11 月 28 日 Working Draft 作为 Exclusion Draft，并给出已于 2025 年 4 月结束的排除期。孤立阅读，这一行显然落后于 2026 年 8 月的实际进程。

但 W3C 的专门 IPR 页面并未落后。它已经把新的 8 月 6 日至 10 月 5 日机会列为当前状态，把 2024—2025 年那一轮放入历史。8 月 6 日的正式通知还说明，新机会只针对旧参照体中没有出现或不能明显看出的内容。

因此，事实边界必须保持克制：这里没有证据证明 W3C 忘记启动排除程序、隐藏了期限或丢失了专利来源链。相反，专门页面证明程序已运行。缺口只在于正在细化的章程交接文本尚未同步引用它。

开放排除窗口也不等于存在专利争议。IPR 页面报告该组规范没有已知专利披露。机会是一种程序状态，不是对任何参与者的指控，也不能预言一定会有权利要求被排除。

交接单所需字段很少：Snapshot 身份、前一参照体、开放与截止日期、IPR 永久链接，以及以后是否出现新的 Snapshot。它不需要替任何机构判断专利有效性。

实现矩阵不是厂商排行榜

8 月 Snapshot 的退出条件不能用“页面上有几个名字”来满足。每一项功能都应有至少两个相互独立、可互操作的实现，并通过开放测试套件验证。可机器测试的规范性陈述需要逐功能两个合格实现；不可机器测试的陈述需要两个实现展示。相关独立实现还须支持至少两种开放规范的 DID 方法，而且每种方法都要由不止一个实现完成互操作。

公开报告确实列出多个实现者，也提供大量单元格。这是重要证据，但四列名称不等于每项功能都有两份合格证据。真正的判断单位是“功能—规范性陈述—测试—实现”这条链。

页面显示的 3 月 27 日测试时间值得在章程交接中明确。它不能单独证明报告已经过时：某些功能从 3 月到 8 月可能没有变化，测试结果仍有价值。它也不能单独证明标准已经通过或未通过退出门槛：可见的 fail、not implemented 或 pass 都需要结合测试版本、规范版本、功能分组和独立性标准理解。

审计友好的实现收据应包含：

  • 被测规范的发布版或 commit；
  • 测试套件 commit 与运行时间；
  • 每项功能包含哪些规范性陈述；
  • 对应的两个实现或两个展示；
  • 独立性认定依据；
  • 用于互操作的开放 DID 方法；
  • 未覆盖、跳过与 at-risk 项；
  • 报告刷新责任人。

这才是 running code 对制度标签的约束。章程可以要求证据，却不能靠写下“实现充分”来生成证据。

“有风险”是受控的不确定性

8 月 6 日 Snapshot 将 DID URL dereferencing 标记为 feature at risk，表示它很可能修改或删除，工作组正在向实现者询问该功能的价值。状态说明还提醒，公开议题中的 class 1、2 或 3 事项可能改变规范。

这不是失败声明。Candidate Recommendation 本来就是让实现经验反过来检验文本的阶段。把一项功能标为 at risk，说明工作组没有把尚未验证的未来伪装成既成事实。

真正的风险是章程交接只继承“维护 DID Resolution”这句话，却遗失该功能当时所处的开放状态。交接单应保留功能身份、关联 issue、所需证据、决定主体与将来的处置结果。最后无论保留、修改还是删除，都能还原为什么发生。

记录不替工作组做技术判断。记录只确保行政边界不会抹掉技术问题。

Refinement 正是用来修正草案的

公开页面标题写着 DRAFT。开始和结束日期仍是占位符并不异常，因为新章程的起点取决于批准后的 Call for Participation。W3C 公告预计细化持续到大约 9 月 15 日。

按照 Process，refinement 阶段要进行广泛审查、正式处理所有议题，并由 W3C Team 决定送交 AC Review、延长细化或放弃提案。把草案中的旧数据直接描述成程序失效，会把草案误当成最终决定。

但草案自己也给出了明确标准：“Draft state”应表示章程获批时的交付物状态，并另行链接动态发布页面。它无需每小时同步，却必须在批准时准确。

截至证据截止点，8 月 27 日合并的仓库头仍保留 Working Draft、7 月 10 日与 2024 Exclusion Draft，虽然 8 月 6 日 Snapshot 已发布三周。8 月 28 日 CR Draft 又增加一个需要说明的新状态。

结论因此很简单：这是可在 refinement 内修正的状态差异，不是无效证据。否认差异，会浪费细化；用差异宣布章程无效，同样会否认细化的作用。

一张足够薄的交接单

W3C 已有发布历史、IPR、工作组与测试页面。新章程无需复制它们。共同层只需保存跨页面都必须一致的最小字段：

  1. **权限：**现行章程及有效期、提议章程 commit、细化阶段与最终采纳决定。
  2. **文本：**最新可读技术报告与控制专利状态的 Snapshot 分栏记录。
  3. **专利：**Patent Review Draft、排除期、前一参照体和 IPR 链接。
  4. **实现：**报告版本、测试时间、被测规范、逐功能覆盖与独立性依据。
  5. **审查：**at-risk 功能、开放 issue、horizontal review、wide review 与意见处置。
  6. **保管：**每个投影的维护者、纠错路径和取代事件。

变化应以追加状态发生，而不是静默覆盖旧值。面向人类的小表格和机器可读记录可以共享同一组稳定身份。

本文关联的 identity and access management 是外围主题，不是权限扩张。草案明确排除认证或授权协议、浏览器 API 和“解决 Web 上的身份”这一目标。DID Resolution 与身份领域有关，不等于 W3C 认证所有 IAM 产品、DID 方法或法律身份制度。

薄记录的价值就在这里：它让协调准确，同时让授权保持有限。

来源

  1. W3C——DID Resolution v1 Candidate Recommendation Snapshot 公共审查公告，2026 年 8 月 6 日
  2. W3C——DID Resolution v1 Candidate Recommendation Snapshot
  3. W3C Patent Policy——DID Resolution v1 Call for Exclusions
  4. W3C DID 工作组 IPR 页面
  5. W3C——DID 工作组章程草案开始 refinement，2026 年 8 月 10 日
  6. W3C——Decentralized Identifier Working Group 章程草案
  7. w3c/did-wg-charter——核验 commit a840d21c6f8fac431ee1662d1bedb05940834623
  8. w3c/strategy——DID 工作组章程第 562 号议题
  9. W3C——2024 年 4 月 25 日生效的现行 DID 工作组章程
  10. W3C DID 工作组页面
  11. W3C——DID Resolution v1 发布历史
  12. W3C——DID Resolution v1 Candidate Recommendation Draft，2026 年 8 月 28 日
  13. W3C DID Resolution 实现报告
  14. W3C Process Document，2025 年 8 月 18 日