由英语自动翻译。查看原文 →
Conditional Create 率衡量浏览器、身份验证器和凭据提供商支持在何处使通行密钥创建自动化：在密码成功登录后静默进行，无需额外提示。它最好被视为成熟通行密钥推广的采用加速器，而不是注册策略的独立替代方案。
当具备合适的生态系统技术栈时（有关完整的门控逻辑，请参阅下文的先决技术栈），Conditional Create 可在密码成功登录后自动创建通行密钥。下方的四个平台卡片假设每个操作系统使用以下凭据管理器：iOS / macOS 上的 iCloud Keychain (Apple Passwords)、Android 上的 Google Password Manager 以及 Windows 上的 Chrome / Google Password Manager。该范围是针对已存在显式注册提示的成熟部署的附加基准测试；独立部署可能会有实质性差异。
Apple 保持浏览器、身份验证器和密码管理器紧密集成；通行密钥自动填充已为人熟知。
Chrome 和 Safari 在浏览器端覆盖良好；桌面密码管理器的选择比 iOS 更加混杂。
Chrome / Google Password Manager 能够运行；Samsung Internet、Samsung Pass 及默认提供商设置导致就绪度碎片化。
Chrome / Google Password Manager 能够运行；Windows Hello 不是一条 Conditional Create 路径，且 Edge 降低了就绪度。
由于浏览器、身份验证器、密码管理器和通行密钥自动填充行为紧密集成，iOS 是最强大的环境。macOS 也可行，但情况更复杂。Windows 和 Android 目前面临的阻力最大：Windows Hello 不是 Conditional Create 路径，而 Android 很大程度上取决于所选的凭据提供程序、制造商以及由此产生的默认设置。在三星占据主导地位的市场中，如果未为用户设置首选服务路径，仅有 Google Password Manager 是不够的。
浏览器支持只是第一道关卡。Conditional Create 还需要提供程序 / 身份验证器支持、最近使用保存的密码自动填充登录，并且活动的凭据提供程序中没有现有的通行密钥。请参阅 Corbado Conditional Create 分析。
2025年12月的功能支持情况说明了跨操作系统汇总的浏览器端上限。此表格纯粹关于浏览器是否公开 Conditional Create，与底层身份验证器或操作系统无关。iOS Chrome、Edge 和 Firefox 被单独列为 WebKit 上下文；非 iOS Firefox 在此数据中未显示出对 Conditional Create 的支持。这仍然没有衡量已保存密码的自动填充份额。
| 浏览器 | 支持 |
|---|---|
| Chrome | 96% |
| Safari | 95% |
| Edge | 4% |
| Chrome iOS WebKit | 98% |
| Samsung Internet | 0% |
| Firefox | 0% |
Corbado 精选研究与主要参考资料。