摘要

  • remoteClientDataJSON默认不可用，必须逐来源授权；但本地浏览器放行某个调用来源，只能证明本地能力已开启，不能证明远程客户端确实正确校验了远端来源与RP ID。
  • 部署者应在远端校验、本地调用和RP服务器验收之间保存哈希绑定的跨客户端回执，同时保留草案的分工，不要求本地浏览器重做远端全部校验。

2026年9月15日发布的Web Authentication Level 4首份公开工作草案，最值得关注的并不是又多了一种密码算法，而是校验责任从一个执行环境跨到了另一个执行环境。

普通WebAuthn流程依赖浏览器眼前的执行上下文。浏览器知道调用页面的来源；RP ID通常必须等于该来源的有效域，或是它的可注册域后缀，相关来源机制另有一套受限程序。浏览器构造clientDataJSON，认证器签署其哈希，依赖方服务器再检查仪式类型、挑战值、预期来源和RP ID哈希。

远程桌面把这条链拆开了。真正发起认证的网站或应用运行在远端主机，本地机器却持有用户的认证器。若本地浏览器仍按自己的页面上下文重新构造客户端数据，写进去的会是远程桌面Web客户端的本地来源，而不是远端会话里的依赖方来源。即便语义完全相同，JSON字段顺序、可选字段或空格不同，也可能改变哈希，使远端机器无法验证签名。

remoteClientDataJSON扩展的目标，是让获得授权的远程桌面Web客户端把远端生成的完整客户端数据字符串交给本地浏览器。本地浏览器解析它，但不能增加、删除或修改内容；在序列化步骤直接把输入用作clientDataJSON，从而让认证器签署与远端机器预期一致的字节。

这不是无条件覆盖。草案把publickey-credentials-remote-client-data-json同时定义为强能力和Permissions Policy受控能力，默认权限状态是denied，写明的默认允许列表是'none'。配置必须精确到来源，用户代理不得提供“一次允许所有来源”的选项。草案倾向由受管浏览器、受管设备策略或浏览器设置中的逐来源用户选择来授权，而不是在仪式进行中临时弹窗诱导点击。

这些边界很重要，但它们回答的是本地问题：当前这个调用来源能否使用扩展？它们没有回答远端问题：远程客户端是否正确识别了远端RP来源，又是否按当时适用的规则确认RP ID可以用于该来源？

算法对这条边界写得很直白。本地权限不是granted就抛出NotAllowedError；请求还必须显式提供RP ID；远程JSON必须能被解析。完成这些检查后，本地浏览器跳过RP ID与远程JSON中origin之间通常要做的域关系判断。草案明确说，所有与RP ID有关的来源检查都委托给远程客户端。安全注意事项进一步要求：授予权限的用户代理必须信任调用者准确、诚实地提供远端RP来源，也必须信任远程客户端诚实、正确地完成RP ID校验。

这正是不能把多个“成功”合并成一个“证明”的原因。扩展输出为true，只表示扩展已经被执行。它不携带远程会话身份、校验策略版本、相关来源证据或远端校验结果。字节未被改写，只能证明本地浏览器没有重新拼装数据；它不能证明这些字节里的origin陈述本身真实、当前有效或得到授权。

认证器签名同样有明确边界。它把认证结果绑定到给定的客户端数据哈希和认证器数据。依赖方服务器仍必须检查类型与挑战值、验证客户端数据中的来源，并核对预期RP ID对应的rpIdHash。这些检查不可省略，却也不会自动记录：由哪个远程客户端执行了委托校验、当时采用什么策略版本、远程会话通过哪条已认证通道与本地调用关联。

这不是对漏洞、利用或事故的断言。Level 4文本是首份公开工作草案，不是W3C推荐标准，更不是浏览器实现、互操作或生产部署的证据。W3C状态说明明确指出，首份公开草案不代表W3C及其成员认可，文件仍可能更新、替换或废止。W3C WebAuthn仓库另有一个仍开放的问题，追踪'none'在依赖的Permissions Policy草案中尚未成为规范性默认允许列表术语；该问题称预期行为已经清楚，并明确没有要求改变行为。

因此，治理补丁不应当否定委托。远程侧掌握本地浏览器未必拥有的上下文，包括相关来源文件和平台应用关联规则。如果强迫本地浏览器完整复现远端校验，两个校验器就可能各自演进，重新制造扩展试图消除的不一致。

更窄、更可行的办法，是在责任交接处生成一份跨客户端来源校验回执。它至少应把本地调用来源与授权策略主体、版本、签发时间和失效时间，绑定到远程会话及已认证通道；记录远程来源、RP ID、校验算法与版本、校验结果，以及相关来源或应用关联证据引用；再写入原始remoteClientDataJSON字节的哈希，并由RP服务器的验证结果闭合整条链。例外、撤销与纠正都应追加记录，不能覆盖原决定。

这份回执是部署治理措施，不是本文声称的WebAuthn规范要求。它的任务是把几类事实分开保存：本地能力获得授权、远端完成校验、字节保持一致、用户与认证器发生交互、RP服务器接受或拒绝结果。一个绿色的“WebAuthn成功”事件，承担不了这五层含义。

来源