Passkey 能识别用户吗？WebAuthn 的隐私边界

Passkey 通过 WebAuthn 创建和使用公钥凭据。浏览器也可以提供有限的信息，说明某些 WebAuthn 流程是否可用。这些结果能帮助依赖方决定展示哪些登录选项，但只是功能提示，不能作为硬件清单、用户身份证明、凭据存在证明，也不能保证后续登录成功。BotBrowser 可以在受控上下文中让 WebAuthn 能力结果与同一份配置保持一致，但不能把这些结果变成设备或凭据的证明。

这个区别关系到隐私，也关系到产品设计。能力结果可能受浏览器支持、操作系统策略、账户状态、可用认证器和当前上下文影响。把它当作设备的确定描述，就是从兼容性输入作出了没有依据的推断；把它当作凭据结果，则可能让用户遇到令人困惑的登录流程。

WebAuthn Level 3 规范定义了相关浏览器接口和凭据操作。MDN 的 PublicKeyCredential 参考提供浏览器侧说明。这些资料支持一个需要区分的模型：能力可用性、用户验证、认证器使用、凭据创建和凭据获取彼此相关，却不是同一个事件。

TL;DR

• isUserVerifyingPlatformAuthenticatorAvailable() 返回一个布尔值，说明此刻能否发现会验证用户的平台认证器，它不指名认证器、传感器、账户或凭据。
• isConditionalMediationAvailable() 只表示条件式调解是否可用，不是登录结果；方法缺失或返回 false 时，页面仍要保留另一条可见的登录路径。
• 安全上下文、来源和 RP ID 限定了每一次凭据操作：navigator.credentials.create() 与 navigator.credentials.get() 只有对签发挑战的 RP ID 才会产生服务器能验证的结果。
• 用户取消提示、挑战过期、RP 不匹配和认证器不支持是四种不同结局，任何一种都不该写进长期的账户属性。
• BotBrowser 可以按文档重复一组客户端能力配置，用来确认登录页在能力不同的情况下仍展示回退路径，但它不能创建认证器硬件、写入凭据或验证断言。

目录

• 观看视频
• 来源与主张映射
• 能力结果究竟表示什么
• 来源与依赖方边界
• WebAuthn 提示的隐私限制
• 如何设计尊重用户的登录流程
• 实践结论

观看视频

这段英文视频检查页面可以通过 WebAuthn 能力查询读到哪些答案：先在声明了三组能力的本地实验页面上，再在 Windows 和 Ubuntu 上的两个真实 Chrome 版本中。检查不会创建凭据，也不证明身份、匿名性、访问结果或远程网站的判定。音轨为英文。

来源与主张映射

• 安全上下文与 PublicKeyCredential（规范/API 依据）： MDN 的 PublicKeyCredential 参考说明安全上下文要求。**文章建议：**把它当作兼容性门槛，而不是认证器或凭据存在的证据。
• 平台认证器可用性（规范/API 依据）： W3C 第 5.1.6 节和 MDN 方法参考定义的是可用性检查，而不是凭据存在证明。**文章建议：**只用布尔值决定是否提供平台认证器路径。
• 条件式调解（规范/API 依据）： W3C 客户端能力章节与 MDN 条件式调解参考描述的是可用性提示，而不是登录结果。**文章建议：**方法缺失或不可用时保留其他登录路径。
• 来源、RP ID 与凭据操作（规范协议规则）： W3C 来源与 RP ID 规则将凭据限定在依赖方范围内，凭据操作算法要求请求、用户参与和经过验证的响应。**文章建议：**只有在服务端验证响应后才作账户、授权和恢复决定；不要从能力提示推断这些结论。

能力结果究竟表示什么

PublicKeyCredential 接口只在安全上下文中可用。因此，安全传输是使用 WebAuthn 的前提，但不能证明认证器或凭据可用。页面无法访问 WebAuthn，可能是因为上下文不安全、浏览器不支持相关接口，或者某个可选方法不存在。这几种情况需要不同的用户界面处理。

WebAuthn Level 3 第 5.1.6 节定义了 isUserVerifyingPlatformAuthenticatorAvailable()。依赖方可以用它判断，是否能够通过具备用户验证能力的平台认证器创建新凭据。结果是一个布尔值，由客户端平台发现可用认证器的过程决定。结果为真，可以帮助应用决定是否提供平台注册选项；它不会给出认证器名称、揭示某种传感器、证明特定用户已经完成设置，也不确认该网站已有注册凭据。

这里的“平台”有特定含义。在 WebAuthn 中，认证器的附着方式和用户验证能力是协议概念，并不意味着网站可以把一个布尔值解释为用户的生物特征或硬件事实。设备可能有多个认证器，用户也可能在实际操作时选择另一个。设置、企业策略、账户配置或认证器变化，都可能影响流程开始时能使用的选项。

Level 3 第 5.1.7 节把客户端能力描述为有限的一组能力键，用于提供特定流程和体验。这比身份识别或设备分类的用途窄得多。例如，结果可以帮助登录页面决定是否在用户名输入框旁展示某个选项，却不应该用于给访问者贴标签、推断凭据存在，或决定无需提供密码恢复。

条件式调解也需要同样谨慎。规范把 isConditionalMediationAvailable() 定义为条件式调解的可用性提示。它可以帮助应用选择界面，却不会执行登录，也不表示当前依赖方有可用 passkey。MDN 将其列为 PublicKeyCredential 的静态方法，并说明支持该 API 的浏览器仍要求安全上下文。如果方法不存在或结果表示不可用，应用应保留其他登录路径。

可用性、用户验证与凭据的区别

可用性是第一层：浏览器能否在当前环境提供某个 WebAuthn 选项。它不表示用户能够完成认证。用户验证则是另一层，是凭据操作中请求并评估的属性；认证器可能需要按照请求和自身策略验证用户。能力结果并没有完成这一步。

认证器可用性也不同于凭据可用性。平台认证器可以可用，但用户尚未为某个网站创建凭据；反过来，用户可能持有有效凭据，却需要通过应用没有预期到的另一种认证器使用它。判断登录能否完成，需要在用户选择该路径后，用正确的依赖方数据执行正常的 WebAuthn 请求。

凭据创建和断言是主动操作。注册时，依赖方发起请求，浏览器与认证器随后可以创建新的公钥凭据。认证时，它们可以为已有凭据生成断言。这些操作可能成功，也可能被用户拒绝或取消、不可用，或者因请求相关的其他原因失败。能力查询不能替代其中任何一种操作。

Level 3 对 PublicKeyCredential 接口的说明体现了这种区别：新凭据创建或断言请求完成后，返回的凭据包含响应；能力方法返回的则是用来指导潜在流程的信息。应用的界面和遥测应将它们记录为不同状态。“可以提供这个选项”不等于“用户已同意”“凭据已创建”或“断言已验证”。

取消需要明确处理。用户可能关闭或拒绝认证器提示。这不是关于其身份、硬件，或其在所有情境下使用 passkey 意愿的证据，而是一次交互结果。应用应提供清晰的返回路径，让用户改用密码、恢复流程或其他受支持方式；没有新的用户动作，不应重复发起操作。打开认证流程前说明选择，结束后让用户能方便地返回，才是完整的交互。

错误也应如此处理。认证器不可用、服务端挑战过期、RP 不匹配、账户变化和浏览器策略，都可能产生不同结果。产品团队只应记录协助用户所需的诊断信息，不要把失败类别转换成持久的个人画像。浏览器权限与指纹识别概述进一步说明了为什么浏览器状态应被视为有限信号，而非身份事实。

来源与依赖方边界

WebAuthn 明确限定了作用范围。Level 3 规范说明，操作受到特定来源约束，请求者的完整来源会包含在认证数据中的客户端数据里，并受到相应签名保护。每个凭据还受依赖方标识符，即 RP ID 限定。认证器限制为某个 RP ID 创建的凭据，只能用于符合该 RP ID 的请求。

这些边界解释了为什么能力结果不能证明跨站凭据访问。网站只能通过符合自身来源和 RP ID 的操作获取断言，并接受浏览器验证与认证器处理。通用能力提示不能代替协议中的来源和依赖方检查。安全上下文要求也属于这一安全模型。

对应用而言，规则很具体：只为预期的网站来源和 RP ID 发起注册或登录操作，让浏览器与认证器履行各自职责；按照 WebAuthn 协议验证服务端收到的响应后，才能将登录视为完成。不要根据客户端能力响应决定账户是否存在、授予权限，或裁剪恢复方式。

相关来源需要明确配置，不能依靠猜测。规范包含在相关来源之间使用 WebAuthn 的规则，但组织名称相同或主机名相似，本身并不构成凭据关系。运营多个网站的团队，应在推出 passkey 流程前确定 RP ID 和来源策略，在受支持域名上测试，并说明关系不适用时的替代路径。

来源边界也有隐私价值：它限制依赖方使用为另一个依赖方签发的凭据。但这不代表网站自己的数据采集天然保护隐私。网站仍须减少日志收集、解释提供认证选项的原因，并避免把兼容性信息用于无关画像。

WebAuthn 提示的隐私限制

能力信息可以与其他浏览器信息一起被使用。它有助于兼容性决策，也会随软件、策略或账户状态变化。因此，它既不是稳定标识符，也不能可靠描述实体设备，更不能证明访问者拥有某台设备、使用某种生物识别方式，或在某个依赖方处拥有账户。

这对数据保留尤其重要。一次访问中，用布尔值或小型能力记录来选择可见登录选项，可能已经足够。没有必要把它变成账户属性、分析维度或长期标识符。为无关目的保留它，会增加以后误解临时兼容性状态的风险。若确需诊断日志，应设定较短保留期限、限制访问，并说明收集的运营原因。

网站还应区分用户主动提供的信息与从浏览器支持情况推断的信息。用户在表单中输入账户标识、明确选择登录方式，以及完成凭据操作，含义和隐私预期不同。功能提示不属于其中任何一类。展示 passkey 选项不等于同意开始认证；拒绝提示也不等于同意网站保存关于个人的偏好。

无障碍与恢复同样依赖这种区分。有人使用外部认证器、共享设备、辅助技术，或不同于典型平台认证器流程的账户恢复方式。能力结果不应移除这些人需要的路径。选项名称应围绕提供的动作，不猜测用户设备；用户退出流程时，也不应丢失已有进度。即便 WebAuthn 完全受支持，这些设计仍能改善体验。

支持团队也需要准确表述。报告可以说展示了 passkey 选项、用户取消了操作，或服务端未能验证断言；却不应根据一个功能结果，断言用户缺少生物识别硬件，或浏览器必然属于某类环境。限定描述范围，既保留排查价值，也避免把协议状态变成身份结论。

隐私浏览也需要限定结论。浏览器可能在隐私上下文中采用不同的存储、账户、权限和凭据行为。WebAuthn 规范并未要求每个隐私窗口都返回与常规窗口相同的能力值，或完成同样的操作。应用应测试其支持的浏览器和模式，并在 WebAuthn 不可用时保留替代路径。不能告诉用户隐私浏览会使响应完全相同、匿名或可预测。

显示模式同样不能支持普遍结论。窗口模式与无头环境可能因浏览器构建、操作系统、策略、可用认证器和测试配置而不同。标准定义 WebAuthn 语义，并不保证两种模式结果一致。需要跨环境兼容的团队，应测试自己的支持矩阵，并只报告实际观察到的范围；不能用单个结果概括所有无头或桌面浏览器。

移除接口、替换浏览器方法或强制某个结果，并不是可靠的隐私控制。这可能令应用的兼容性判断失准，或中断认证流程。面向用户的账户流程也不能承诺某种配置对网站不可见，或不会产生其他推断。隐私主张应限于用户能观察到、产品文档能支持的行为。

对用户来说，更实用的问题是：网站是否解释了 passkey 选项的作用？能否选择其他登录方式？网站是否在用户选择该路径后才请求凭据？是否只保留安全运营账户所必需的信息？这些问题比试图从功能提示读出身份或硬件的确定结论，更便于行动。

Navigator 属性与指纹识别指南介绍了更广泛的原则：浏览器的单个值可以是兼容性输入，但含义取决于上下文。隐私决策应关注数据最小化、容易理解的选择，以及受支持行为的测试，而不是把一个 API 响应当作完整画像。

如何设计尊重用户的登录流程

把 passkey 作为明确的登录或注册选择。能力提示可以帮助决定是否突出展示选项，但是否继续应由用户决定。当能力缺失、可选功能不受支持、用户拒绝或操作未完成时，密码、恢复或其他受支持路径仍应可见。替代路径是登录体验的一部分，不是事后才考虑的异常处理。

界面文字应简洁、具体。可以说明为当前账户创建或使用 passkey，但在认证操作产生结果并由服务端验证之前，不要声称凭据已经可用，也不要暗示用户必须具备某种硬件。用户可能使用受支持的外部认证器、另一台设备，或其他登录方式。

产品逻辑应区分兼容性检查与凭据操作。前者影响展示；后者需要依赖方请求、浏览器和认证器处理，以及用户参与。取消或失败后，让用户回到容易理解的选项，而不是推断永久偏好。限流、欺诈控制与账户安全策略应使用各自有依据的输入，不把 WebAuthn 可用性改造成风险评分。

测试流程时，应覆盖操作结果，而不是试图推导设备画像。测试可选能力不可用的浏览器、选择其他方式的用户、取消、成功注册，以及服务端验证成功的登录。还应测试支持的来源和 RP ID 组合。浏览器或操作系统更新后重复这些检查，因为可选支持和错误处理可能变化。

明确服务边界。浏览器、认证器和依赖方有不同职责：依赖方创建请求并在服务端验证响应，浏览器协调交互，认证器执行协议职责。能力响应并不把凭据交给网站，也不能被描述为创建、获取或共享凭据的同意。超出预期服务边界的账户变更或数据传输，需要明确的用户选择。

BotBrowser 的文档说明了由配置文件控制的 WebAuthn 客户端能力。如果你在做经授权的隐私或兼容性测试，可以据此重复一套有文档记录的浏览器配置，并检查在 passkey 选项不同时，你的登录页面是否仍提供备用方式。BotBrowser 无法证明或创建实体认证器硬件、凭据注册状态或已验证的登录，也不能控制你作为依赖方的 origin 与 RP ID 规则、服务器端验证或数据保留策略。请依据公开 WebAuthn 定义和你自己的账户流程验证受支持配置。配置文件管理指南介绍了管理浏览器配置文件的一般方法，而不会把配置设置变成身份主张。

公开来源

• W3C Web Authentication：WebAuthn Level 3：第 5.1.6 节定义用户验证平台认证器可用性方法；第 5.1.7 节定义客户端能力；第 5.1 节和安全模型说明安全上下文、来源、响应及 RP ID 范围。
• MDN：Web Authentication API：注册、认证与 passkey 的浏览器侧概述。
• MDN：PublicKeyCredential：安全上下文要求和静态方法，包括条件式调解与用户验证平台认证器可用性。

实践结论

在接进界面之前，先决定每个答案允许改变什么。isUserVerifyingPlatformAuthenticatorAvailable() 返回 true 可以把 passkey 按钮放得更醒目，isConditionalMediationAvailable() 返回 true 可以开启条件式的 navigator.credentials.get() 路径，但两者都不能让密码和找回入口消失。这两个布尔值都不构成隐藏入口、写入账户标记或判断无需找回的理由。

然后测结局，而不是测设备。覆盖可选方法缺失的浏览器、选择密码的用户、被取消的凭据操作、完成的注册，以及服务器按声明挑战和 RP ID 验证通过的登录。日志只保留分支和结局，诊断字段随 case 一起过期。

如果发布里包含一组由配置控制客户端能力的方案，就用同一页面在其上重跑，确认 passkey 支持不同时回退入口仍然出现。把浏览器构建、配置版本、来源和 RP ID 与这次结果一起记录下来，并把它描述为一种已支持的配置，而不是对访客可能带来的任何认证器的结论。