摘要

  • W3C 于 2026 年 8 月 25 日把 Web Authentication Level 3 发布为推荐标准，并链接一份截至 6 月 26 日的固定实施报告。
  • 报告称共有 53 个测试、415 个子测试，分别展示 Chrome、Firefox、Safari 预览版和 Edge 的指定版本、环境与结果；这些字段证明测试在哪里运行，却没有逐功能说明实现谱系。
  • 最终过渡申请只说 Chrome 与 Edge 的“部分实现不同”。更透明的做法不是简单合并或拆分两款浏览器，而是为每项功能记录实现层、独立性依据及其在决策中的用途。

四列数据，回答的是运行问题

8 月 25 日，W3C 发布《Web Authentication: An API for accessing Public Key Credentials — Level 3》推荐标准。它定义网页应用如何通过用户代理与认证器创建和使用限定作用域的公钥凭据。状态说明写明，W3C 建议广泛部署；自 5 月 26 日候选推荐快照以来，正文没有实质变化。

该固定版本把实施报告放在首页元数据中。报告本身也有清楚的时间边界：这是 6 月 26 日的 web-platform-tests 快照，不再维护，开发者若要看最新状态应去实时服务。页面称 /webauthn/ 下有 53 个测试、415 个子测试。

执行环境记录得很细。Chrome 151 与 Firefox 154 alpha 于 6 月 25 日在 Linux 上运行；Safari 246 预览版于 6 月 26 日在 macOS 上运行；Edge 151 同日在 Windows 上运行。四组结果都指向 WPT 提交 d41367df1e。表格随后逐项显示 PASS、FAIL、TIMEOUT、ERROR、NOTRUN 或缺失。

这些栏位能可靠回答一个问题：某个明确版本的产品，在某个环境中，针对同一组测试代码报告了什么结果。它们不能自动回答另一个问题：针对规范中的某项功能，哪些结果来自相互独立、又能互操作的实现？

这里不能靠品牌数量推断，也不能反向断言两个产品处处相同。浏览器产品可能同时调用浏览器引擎、操作系统、平台认证器与供应商组件。两款产品可以在一项功能上共用相关路径，在另一项功能上走不同路径。独立性是“功能与层”的属性，不是永久贴在产品名称上的标签。

过渡记录承认差异，却没有给出坐标

最终 Recommendation 过渡申请在“Implementation”部分链接实时 WPT 页面和固定快照。紧接着只有一句说明：Chrome 中有一部分实现与 Edge 不同。

这句话阻止了另一种粗暴判断——不能因为两款产品之间存在共同基础，就把所有结果一律合并。记录明确说存在差异。但它没有指出是哪一部分、哪项功能、哪组测试或哪条组件边界，也没有说明判断差异所依据的公开证据，更没有告诉读者某一对 Chrome/Edge 结果是否承担了“独立实现”的证明责任。

3 月 18 日工作组会议记录表明，参与者确实意识到了这个问题。在“Testing”议题下，有发言提到 Edge 相对“普通 Chrome”存在一些技术差异。随后讨论又询问 Microsoft Authenticator 是否经由 Android 或 iOS，并在某个扩展的 WebAuthn 层把两者描述为两个实现。会议末尾记录了在解决待办问题后提请 Recommendation 的共识，没有反对意见。

因此，问题不是工作组没有思考实现独立性。恰恰相反，会议记录留下了分层思考的痕迹。信息在进入最终公开凭证时被压缩了：具体技术差异变成“部分”，特定扩展和特定层变成笼统的产品说明。测试矩阵与差异说明相邻，却缺少把二者连接起来的索引。

最终决定本身已经完成。过渡 issue 记录了 7 月 17 日批准，咨询委员会审查于 8 月 18 日以共识且无正式反对结束，8 月 19 日批准作为 Recommendation 发布，8 月 25 日给出固定链接。本文不把这些已完成状态重新说成待定，也不以公开说明的粒度推断内部证据不足。

W3C 流程问的并非“有几款浏览器”

W3C Process 没有设置机械公式。实施经验的作用，是证明规范足够清楚、完整且符合市场需要，从而能够实现每项功能的独立互操作。Team 可以综合考虑：每项功能是否已实现、独立互操作实现是否存在、实现者是否超出规范作者、是否公开部署、证据是否覆盖生态各层，以及是否出现实施困难。

这些命题相关，却不能互相替代。测试通过能够证明被观察到的行为；没有谱系信息，它不能同时证明作者独立性或代码路径独立性。运行在不同操作系统上，对某项平台能力可能至关重要，对另一项纯浏览器逻辑则可能无关。四组运行使用同一 WPT 提交，提高了可比性，却没有说明被测代码是否独立。

表格里同时存在通过、失败、超时、错误、未运行和缺失，这也不应被做成产品排行榜。一个 FAIL 可能意味着功能尚未支持、实现选择不同或测试预期需要调查；TIMEOUT 与缺失提供的信息更少。W3C 推荐过渡并不要求每个产品的每个格子都变绿，本文也不会发明这样的门槛。

真正缺少的是一条很窄的公开信息：当某些观察被用于证明独立性时，为什么它们针对这一功能可以被如此使用？

给每项功能加上独立性索引

这份索引可以放在测试报告旁边，无需公开专有源代码。每个被用作实施证据的功能或测试组，记录固定规范版本与测试版本、产品和构建、相关实现层，以及经过边界限定的独立性主张。有公开架构资料就链接资料；不便披露细节时，则记录可追责的证明人与证明范围。

同一行还应写明互操作观察，以及该结果是否被用于过渡判断。如果 Chrome 与 Edge 在某个扩展上走不同代码，就只对该扩展标明；如果另一功能经过相同的相关路径，就不能让两个品牌栏默默变成两个独立实现。Firefox、Safari、Android、iOS、认证器和依赖方软件也应适用同样的逐功能纪律，而不是获得永久的“独立/不独立”身份。

索引不是新的审批关卡。W3C Team 继续行使流程赋予的综合判断。它只是拆开证据中本来就不同的三句话：测试在哪里运行、观察到什么行为、为什么该实现针对特定目的被认定为独立。

Lu Heng 在《Minimum Initial Specification》中强调，Recommendation 是协调产物，实施、验证、部署与采用仍是不同事实。同样的克制也适用于实施报告：浏览器名称证明的是被测试产品，不会自动证明其下方的实现谱系。

来源