WebAuthn Level 3 成了 W3C 正式推荐标准：passkey 终于能在你登录时被静默创建，注销也不再靠猜

8 月 25 日，W3C 把 Web Authentication Level 3 正式发布为 Recommendation。这件事最实在的两个变化是：passkey 可以在用户用密码正常登录的过程中被静默创建（Conditional Create），以及服务端注销一个 passkey 后，浏览器的凭据管理器终于能收到通知（Signals API）。

这不是新 API 的诞生，而是两个已经跑了很久的 working draft 变成了可以写进企业认证策略、能被审计引用的正式标准。对写登录页的人来说，它改变了你实现 passkey 的两条边界。

先说清楚今天之前的处境。

Conditional UI 早在 Chrome 108 就进了开发者试验，思路是：用户点开用户名输入框时，浏览器在自动填充下拉里列出已注册的 passkey，选一个、验个指纹就登进去了。不需要用户先去点一个他根本不认识的「用 passkey 登录」按钮。这条路径对 adoption 的影响是数量级的——社区复盘给出的数字是：identifier-first + Conditional UI 的团队，六个月内自愿开通 passkey 的用户占 50% 到 70%；而单独放一个 passkey 登录按钮的团队，这个数字长期停在 10% 以下。

但 Conditional UI 只解决了「登录时怎么用」，没解决「怎么让用户从密码迁移到 passkey」。之前你只能在登录成功后弹一个「要不要给下次登录加个 passkey」的横幅，用户点不点全看心情。

Conditional Create 把这一步变成了登录流程的副产品。触发条件有两个，缺一不可：用户在这个应用里本来就有基于密码的账户；用户刚刚用这个密码完成了认证。满足这两条后，你在密码验证通过之后直接发起创建请求，passkey 就自动落进用户的凭据管理器了。用户全程没有额外操作。

// 用户用密码登录成功后，紧接着发起 conditional create
// 前提：该用户已有密码账户，且刚刚用密码通过了认证
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,        // 服务端生成的一次性随机值
    rp: { id: "example.com", name: "Example" },
    user: {
      id: userIdBytes,                 // 稳定的用户标识字节串
      name: "user@example.com",
      displayName: "Zhang San",
    },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }], // ES256
    authenticatorSelection: {
      residentKey: "required",         // 会被同步的发现型凭据
      userVerification: "preferred",   // 无生物识别的设备也能用
    },
  },
});

这里有个必须知道的取舍：Conditional Create 全程不弹同意框、不给提示。用户不会被告知「刚刚给你建了一个 passkey」。这是它和 Conditional UI 最大的区别，也是争议点——唯一的拒绝方式是用户自己去密码管理器里关掉自动创建。从安全角度这算升级（passkey 比密码难钓），但作为工程方你得知道它是在静默发生的。

第二个变化是 Signals API，它解决的是一个拖了所有 passkey 落地方案后腿的老问题：注销不同步。

账号被关掉、或者服务端把一个凭据删了之后，那个 passkey 之前会一直躺在用户的凭据管理器里，天天在登录框里提示「用这个登进去」，而它指向的账号早就不存在了。凭据管理器那边没有任何标准途径知道「这个凭据已经废了」。Signals API 给了协调生命周期事件的正式通道，注销和改名都能通知到凭据管理器。这是第一个标准答案。

同一批进入正式推荐状态的还有几个：

• Related Origin Requests：一个 passkey 能跨相关域名使用。app.example.com 和 admin.example.com 共用一个 rpId 下的凭据，不用每个子域各注册一个。
• Backup Eligible / Backup State 标志：RP 能区分一个 passkey 是跨设备同步的还是绑死单台设备的，并读到它当前的备份状态。这直接影响你的风控判断——同步凭据和硬件密钥的风险模型完全不同。
• PRF 扩展：从凭据派生稳定的每凭据密钥材料，可以拿来做端到端加密的密钥。
• AAGUID without attestation：不做 attestation 也能识别 passkey 存在哪个凭据管理器里。

如果你现在就要动手，落地顺序建议是：先给现有的密码登录加 Conditional UI（autocomplete="webauthn" 加上 mediation: 'conditional'），这是最低成本的改造；等 Conditional Create 的浏览器支持跟上后，再把它接到密码登录成功的那一步上，让迁移变成登录的副产品。记住始终保留密码路径作为回退——不能让 passkey 成为用户唯一的登录方式。

下一步：先去查一下你自己的登录表单，那个用户名输入框上有没有 autocomplete="webauthn"。没有的话，这就是你今天能改的第一行。