摘要

  • Web Authentication 工作组拟议章程把“对其他数据签名”列入工作范围：签名由 WebAuthn 中介，所用密钥与认证凭证关联，但必须和认证密钥分离。
  • 章程以智能体式 AI 和可验证数字凭证为例，同时仍排除对私钥或底层密码操作的直接访问，也不接纳超出列明功能的独立通用密码 API。
  • 纳入范围只是起点。章程审议尚未结束，Level 4 尚无 FPWD，sign 拉取请求仍为 Draft，说明文档没有用户研究，也没有 Chrome、Firefox、Safari 或 Edge 的立场信号。
  • 应为这项功能建立公开的“准入凭据”，把章程权限、具体提案、密钥与消息边界、用户同意主张、横向审查、测试、独立实现、Recommendation 状态和实际采用逐项连接起来。

章程打开的是工作入口，不是技术结论

现行 Web Authentication 章程的中心很清楚：让 Web 应用使用基于公钥的强认证。它覆盖绑定来源的凭证、持有证明、恢复和备份等能力，同时把底层密码操作和密钥材料的直接访问排除在外。普通网站可以请求认证仪式，却拿不到认证器内的私钥。

正在审议的新章程改变了这条边界。其范围第 11 项允许工作组研究“签署其他数据”，包括经 WebAuthn 中介的原始签名。它要求签名密钥与认证凭证密钥不同，并把智能体式 AI、可验证数字凭证生态列为应用语境。接下来的两项还分别涉及凭证管理器的信任信号和扩展数据的保密性。

这种改变确实重要。一项能输出常规密码签名的 Web API，不再只服务于登录。钱包、授权令牌、软件发布以及其他现有验证器已经理解的协议，都可能借它使用硬件保护的密钥，而不必把私钥交给 JavaScript。

但正在发生的制度动作要窄得多。W3C 于 8 月 10 日发起章程审议，意见窗口到 9 月 7 日 23:59 UTC 关闭，现行章程则延长到 10 月 30 日。本文截点时，新章程仍未获批。即使之后获批，它回答的也只是工作组是否有权研究这一类功能，而不是当前拉取请求是否被选定、风险是否已解决，或浏览器是否必须实现。

章程自身也保留了这种区分。Web Authentication Level 4 被列为拟议规范性成果，但页面明确写着还没有 First Public Working Draft，预计完成时间为 2028 年第四季度。把一个议题写进授权文件，与把稳定代码交到用户手里，中间仍有很长的路。

“任意数据”说明的是能力，不说明人的意图

WebAuthn 原本就会产生签名，但普通认证断言并不直接签署网站发来的挑战值。认证器签署的是规定好的结构，其中包含认证器数据和客户端数据的哈希。原始签名提案有意改变这一点：应用提交什么输入，结果就对那段未经改写的数据签名。

这正是它的价值。许多既有协议会验证常规签名，却不认识 WebAuthn 断言的外层结构。如果浏览器和认证器可以在不泄露私钥的前提下签署指定消息，Web 应用就更容易接入那些协议。

提案也试图保留 WebAuthn 的关键隔离。新签名密钥必须与父凭证密钥不同，并且在密码学上互不相关，避免恶意依赖方利用新接口制造看似有效的认证断言。来源绑定旨在防止一把签名密钥变成跨站跟踪标识。最低“用户在场”和“用户验证”政策在密钥创建时固定。面向网页的接口不应提供无人值守签名，尽管更低层的客户端到认证器协议可能服务具有不同规则的原生应用。

这些都是实质性的设计承诺，却都不能证明一个人理解了消息。

说明文档把“交易确认”明列为非目标。它接受输入可能是人无法阅读的不透明二进制数据，也不要求可信界面先把内容清楚展示给用户。一次成功仪式可以证明某把密钥在规定的在场或验证政策下执行了操作。单凭这一点，不能证明用户读过文件、理解付款、同意后来附加的法律效果，也不能证明一个自主智能体有权选择那段消息。

这不是外部批评强加给提案的缺陷，而是提案公开承认的能力边界。治理问题出现在后续产品宣传抹去这条边界时。“用户已验证”是一项仪式属性；“用户理解了载荷”是另一项主张；“用户授权智能体决定载荷”又是第三项。

现有材料仍处于孵化和取证阶段

原始签名说明文档写明尚未开展用户研究。在利益相关方表格里，Chrome、Firefox、Safari 和 Edge 都没有给出信号。一家认证器实现方和一家依赖方实现者表达了积极态度。“没有信号”不是“反对”，也不应被包装成“默认支持”；它只表示立场仍未确定。

对应的 sign 扩展位于第 2078 号 Draft 拉取请求，并挂在 Level 4 首份公开工作草案的里程碑下。2024 年 9 月，作者曾说明手头有粗略的内部概念验证组件，同时当时没有其他工作组参与者作出承诺。此后的讨论和实验说明工作在推进，却不能替代一份公开的互操作报告，也不能自动证明已有两个独立实现。

W3C 流程给出了不应省略的阶梯。重大范围变化要经过 Advisory Committee 审议与 W3C Decision；FPWD 标志标准轨道的公开工作和相应专利后果；可访问性、国际化、隐私与安全横向审查要检查跨领域风险；Candidate Recommendation 需要最终审查和实现经验；Recommendation 还需要进一步证据与 W3C 决定；最后是否部署，则由浏览器、认证器和依赖方选择。

每个状态回答的都是不同问题：章程问“能不能做”，草案问“设计是什么”，FPWD 问“标准轨道是否公开启动”，横向审查问“风险是否被系统检查”，开放测试问“主张能否复现”，独立实现问“是否跨栈互通”，Recommendation 问“流程是否正式认可”，部署才问“运行系统是否采用”。把这些阶段混成一句“W3C 支持”，不会让工程进度加快，只会让证据失真。

Heng Lu 关于运行代码优先的论述在这里有一个有限而准确的用法：发布或登记可以组织未来工作，却不会让后续改动在运行中自动成为现实。W3C 不是 RIR，Web 标准也不是号码资源登记系统，二者不能被机械类比。可以迁移的只是这条纪律：文档状态、实现证据和采用事实不能彼此冒充。

为一项功能建立一张连续的准入凭据

拟议章程已有全组层面的成功标准，但原始签名需要功能级记录，因为它依赖的主张很容易在不同文件和年份间走散。

凭据应先标出章程条款及其当前状态，再指向精确的说明文档和规范修订版。它要说明实际签署的是完整输入、预哈希还是另一种封装；记录算法标识和域分离约定；解释父凭证与签名密钥的关系、来源边界、固定的在场与验证政策；说明用户到底能看到什么；区分证明材料能够证明什么、不能证明什么；并链接可关联性与指纹风险分析、浏览器和认证器信号、横向审查问题及处置、开放测试覆盖、独立实现证据、未决异议和当前 W3C 成熟度。

这张凭据不应保存私钥、设备标识、个人测试数据或可被利用的实现细节，也不应成为一个拥有额外否决权的新委员会。它只是把现有流程本应产生的公开记录连接成一个有版本、可校正的索引。

校正能力才是关键。如果章程措辞改变，第一行随之更新；如果交易确认后来成为目标，用户控制一栏保留旧边界和新决定；如果浏览器后来明确反对，不会把当年的“无信号”重写成早有反对；如果测试发现协议混淆，结果与处置始终连在一起；如果功能被撤回，也会留下清晰终态，而不是让一段过时章程文字继续充当产品背书。

来源

  1. W3C：拟议 Web Authentication 章程审议通知
  2. 拟议 Web Authentication 工作组章程
  3. 现行 Web Authentication 工作组章程
  4. Web Authentication Level 3 推荐标准
  5. 原始签名扩展说明文档
  6. sign 扩展 Draft 拉取请求 #2078
  7. W3C 流程文件，2025 年 8 月 18 日
  8. Heng Lu：Running-Code Primacy
  9. Heng Lu：Minimum Initial Specification, Localized Future Decision and Voluntary Adoption