WebAuthn Level 4 以工作草案形式发布

2026 年 9 月 15 日，Web 认证工作组（Web Authentication Working Group）发布了 Web Authentication Level 4 的首个公开工作草案 （First Public Working Draft），W3C 的新闻栏目当天即作了公告。草案自己的状态一节写道，这 份发布于 2026 年 9 月 15 日的首个公开工作草案开启了对 Web Authentication Level 4 的公开评 审，并且它建立在 2026 年 8 月 25 日作为 W3C 推荐标准（Recommendation）发布的 Web Authentication Level 3 之上。状态一节还写道，相对 Level 3 的改动记录在草案自身的「Changes since Web Authentication Level 3」一节里 （W3C 新闻，2026 年 9 月 15 日）。

这份草案发布了什么

下面依次交代这份文件的地位、它相对 Level 3 记录的实质改动，以及这些改动引入的那个扩展，用 词一律照规范自己的说法。

这份文件的地位

草案走的是推荐标准轨道（Recommendation track），其状态一节写道，以首个公开工作草案的形式 发布并不代表 W3C 及其成员的认可。它接着写道，这是一份草案文件，随时可能被更新、替换或废 弃，并且把这份文件作为「进行中的工作」之外的任何东西来引用都是不恰当的。同一节还写道，该 文件由在 W3C 专利政策下运作的工作组产出，并受 2025 年 8 月 18 日版 W3C 流程文件约束 （Web Authentication Level 4 首个公开工作草案）。

草案记下了它在这一系列中的位置。它把带日期的版本 URL 写为 https://www.w3.org/TR/2026/WD-webauthn-4-20260915/，把先前版本列为 2026 年 8 月 25 日的 Level 3 推荐标准、2021 年 4 月 8 日的 Level 2 推荐标准与 2019 年 3 月 4 日的 Level 1 推荐 标准，并指向一份编辑草案和一份实现报告。它的编辑列为 Okta 的 Tim Cappalli、Microsoft 的 Akshay Kumar、Yubico 的 Emil Lundberg、Cisco 的 Matthew Miller、Apple 的 Pascoe、Google 的 Nina Satragno 与 Ping Identity 的 David Waite （Web Authentication Level 4 首个公开工作草案）。

W3C 新闻条目引用了这份规范的摘要。它写道，该规范定义了一个 API， 让 Web 应用能够创建并使用强的、带证明的、有作用域的、基于公钥的凭据，用于对用户做强认证； 一个或多个公钥凭据，各自作用域限定于某个给定的 WebAuthn 依赖方（Relying Party），由认证器 按 Web 应用的请求创建并绑定；用户代理对认证器及其公钥凭据的访问进行中介，以保护用户隐私； 认证器负责确保没有任何操作在未获用户同意的情况下被执行；认证器通过证明（attestation）向依 赖方提供其属性的密码学证据 （W3C 新闻，2026 年 9 月 15 日）。

相对 Level 3 的实质改动

草案把它相对 Level 3 的改动记录在一个改动附录里。在实质改动名下，它记录了一项要求，即 prf 扩展 的认证器扩展输出不得包含明文的 PRF 输出；以及对虚拟认证器（Virtual Authenticator）的 「Add Credential」与「Set Credential Properties」命令的扩展，为其加入显式的 signCount 处理，包括创建、更新或移除一个签名计数器的能力 （Web Authentication Level 4 首个公开工作草案）。

在同一附录的新特性名下，它记录了新增 remoteClientDataJSON 这一用于远程桌面 WebAuthn 操 作的注册与认证扩展，并在那里描述为：包含一个默认拒绝的「powerful feature」、一个默认 allowlist 为 'none' 的「policy-controlled feature」，以及面向客户端的安全考量。与之并列 列出的编辑性改动，是为该扩展在凭据创建与认证算法中所用的客户端数据构造与序列化步骤加上显 式锚点，以及为 Set User Verified 虚拟认证器命令定义一个名为「Set User Verified Parameters」的 JSON 对象 （Web Authentication Level 4 首个公开工作草案）。

remoteClientDataJSON 扩展做什么

草案中这个扩展的一节，把远程桌面 Web 客户端描述为让用户从本地客户端 Web 应用去与远端主机 的（原生）桌面环境交互。它写道，这个注册与认证扩展允许用户使用连接在本地客户端平台上的 WebAuthn 认证器，在远程桌面 Web 客户端中登录浏览器里的某个网站，或者登录运行在远端主机上 的某个应用；并写道这让基于 Web 的远程桌面客户端得以在本地执行远端的 WebAuthn 请求。它把扩 展标识写为 remoteClientDataJSON，适用操作写为注册与认证，客户端扩展输入写为添加到 AuthenticationExtensionsClientInputs 上的一个 DOMString 成员 （Web Authentication Level 4 首个公开工作草案）。

草案把这个扩展的权限模型写在同一节里。它写道，这个扩展是一项「powerful feature」，使用前需要显式的按来源 （per-origin）授权；并且用户代理「SHOULD NOT」在请求发生时提示用户授予该权限，授予应改为通 过设备管理策略来施行（它举的例子是受管的浏览器配置文件、受管的浏览器实例，以及枚举了特定 远程桌面 Web 客户端来源的受管设备），或者通过在 WebAuthn 客户端设置里按来源显式选择加入。 它写道，这项权限「MUST」按来源配置，并且「MUST NOT」提供允许所有来源的能力 （Web Authentication Level 4 首个公开工作草案）。

草案点名了这两项特性，并给出了它们的默认值。它写道，这个扩展定义了一项「powerful feature」和一项 「policy-controlled feature」，两者都以名称 "publickey-credentials-remote-client-data-json" 标识；该 policy-controlled feature 的默认 allowlist 是 'none'，默认权限状态是 "denied"，意思是这个扩展默认不可用，必须被显式启用。它指出，由于没有定义额外的方面，权限 描述符类型默认为 PermissionDescriptor，并给出一段代码，展示远程桌面 Web 客户端用 navigator.permissions.query({ name: "publickey-credentials-remote-client-data-json" }) 查询授予情况、并检测 state 是否为 "granted" （Web Authentication Level 4 首个公开工作草案）。

草案的安全考量一节交代了这个扩展对信任模型的影响。它写道，该扩展让远程桌面 Web 客户端能够代表 远端的依赖方代理 Web 认证 API 的请求，而这从根本上改变了 Web 认证 API 的信任模型，改变之 处它随后一一点名：来源替换，即用户代理接受由调用方远程桌面 Web 客户端提供的 origin，而不 是从当前执行上下文推导出来，因此任何授予该权限的用户代理都必须相信调用方准确而诚实地提供 了远端依赖方的来源；RP ID 校验被委托给远程客户端，因为该客户端具备考虑相关来源与平台特定 应用部署模型所需的上下文；以及必须按来源提供配置机制，用户代理只能通过用户代理策略按来源 提供配置。同一节写道，授予该扩展的用户代理「SHOULD」在远程桌面代理的 WebAuthn 操作进行时 向用户清楚传达，以便用户明白自己的认证器正被代表一个远端托管的应用使用 （Web Authentication Level 4 首个公开工作草案）。

对 PWA 开发者为什么重要

MDN 记录了这份草案所扩展的那个 API 的可用性。MDN 把 Web 认证 API 记为 Baseline 普遍可用，写道该特性已经相当成熟，在许多设备与浏览器版本上都能工作，并把它跨浏览 器的可用时间定在 2021 年 9 月，同时附了一条脚注：该特性的某些部分支持程度可能不一。MDN 还 写道，这个 API 仅在安全上下文中可用，在部分或全部支持它的浏览器中如此 （MDN，Web Authentication API）。

MDN 也记录了这个 API 是用来做什么的。MDN 把 WebAuthn 描述为凭据 管理 API（Credential Management API）的一项扩展，它用公钥密码学实现强认证，从而让无密码认 证与不依赖短信的安全多因素认证成为可能；并写道在 Web 上，通行密钥（passkey）就是用 Web 认 证 API 实现的。它把抗钓鱼列为一项好处，理由是制作假登录网站的攻击者无法以该用户身份登录， 因为签名会随网站的 origin 变化 （MDN，Web Authentication API）。

草案交代了这个扩展对一次 WebAuthn 操作所针对的 origin 做了什么。它写道，在 remoteClientDataJSON 之下，用户代理接受由调用方远程桌面 Web 客户端提供的 origin，而不是 从当前执行上下文推导；并且 RP ID 校验被委托给那个远程客户端。它还写道，该扩展的默认权限状 态是 "denied"，这项权限「MUST」按来源配置，并且用户代理「SHOULD NOT」在请求发生时提示用 户授予它 （Web Authentication Level 4 首个公开工作草案）。

草案也交代了这份规范为依赖方提供什么。它写道：用户与账号可以用广泛兼容、易于使用的多因素认证来保护；依赖方不需要给自己的用户配 发认证器硬件，因为每个用户都可以自行取得任何符合规范的认证器，并把同一个认证器用于任意数 量的依赖方；依赖方可以选择通过检视认证器返回的证明声明（attestation statement）来对其安全 属性施加要求；认证仪式（authentication ceremony）能抵抗中间人攻击；依赖方还可以在几乎不改 代码的情况下自动支持多种用户验证方式，它点名了 PIN 与生物特征 （Web Authentication Level 4 首个公开工作草案）。

草案交代了这一系列中两份文件各自的地位。Level 3 是草案自称所建立于其上的那 份推荐标准，日期为 2026 年 8 月 25 日；而 Level 4 是一份首个公开工作草案，同一节状态说明写 道它随时可能被更新、替换或废弃，并且把它作为「进行中的工作」之外的任何东西来引用都是不恰 当的 （Web Authentication Level 4 首个公开工作草案）。

站内相关条目

• Web app manifest：写给要在已安装 PWA 里加入 Web Authentication 登录的读者，这一页是 OpenPWA 记录 Web 应用清单的地方。
• Service workers：同样写给这些读者，这一页是 OpenPWA 记录 Service Worker 的地方。
• By feature：MDN 提示 Web Authentication API 的部分功能支持 程度不一，而这一页是 OpenPWA 按能力跟踪支持情况的地方。

待核实与存疑之处

• Level 4 何时、或者是否会越过首个公开工作草案这一阶段，尚未确认。
• 是否有浏览器已实现 remoteClientDataJSON 扩展、以及在何种条件下实现，尚未确认。
• 相对 Level 3 记录的那些改动，对一个既不使用 prf 扩展、也不使用虚拟认证器命令的既有注册 或认证流程是否有影响，尚未确认。
• 用户代理究竟应如何「清楚传达」远程桌面代理的操作正在进行，尚未确认。
• MDN 在其 Baseline 状态上加脚注所指的「支持程度可能不一」究竟涉及 Web 认证 API 的哪些部 分，尚未确认。
• 草案所描述的来源替换，是否关涉 MDN 归于 Web 认证 API 的抗钓鱼能力，尚未确认。
• 草案那套默认拒绝、按来源的权限模型，是否就是针对该来源替换给出的应对，尚未确认。

参考来源

• First Public Working Draft: Web Authentication: An API for accessing Public Key Credentials Level 4（w3.org）
• Web Authentication: An API for accessing Public Key Credentials Level 4, W3C First Public Working Draft 15 September 2026（w3.org）
• Web Authentication: An API for accessing Public Key Credentials Level 3（w3.org）
• Web Authentication API（developer.mozilla.org）