Passkey的误解

Passkeys 是未来无需密码的身份验证和授权方式。

Passkeys 缩短了注册/登录时间，减少了欺诈，并提高了商业转化率（参见此处的案例研究）。这并非我一家之言，Apple、Google 和 Paypal 都持相同观点。

Passkeys 也是未来无需中介的 Web 原生自托管加密钱包的未来。它们与 YubiKeys 配合使用，使其成为企业级安全性的绝佳选择。

许多人通过 Tempo 主网和 Machine Payments Protocol 的发布体验了这一点。其入职体验流畅、快速、丝滑，并且无需 Chrome 扩展、移动应用程序和助记词——这些都是加密世界中人人厌恶的东西。

如果你不相信这一点，只需在你的代理中运行 “install tempo.xyz/SKILL.md ”，并让它为你完成入职。

尽管在正确集成 Passkeys 方面存在一些历史遗留的粗糙之处，但它们都是可解决的工程问题，其中许多问题我们已在 @tempo 解决。我们在 2024-2025 年构建 Porto 时遇到了许多此类问题。这对于我们的团队来说并非新领域。

现在，我将澄清一些关于 Passkeys 的误解，这些误解是人们在没有深入接触这项强大技术的情况下重复传播的。

其中很多内容是技术性的，并非适合所有人，你的一句话总结应该是“Passkeys 是未来”。如果你是技术人员，欢迎加入讨论，让我们进行一场开放、求真的辩论。

请深思熟虑地参与。

Myth 0: Passkeys的浏览器和手机支持度

Passkeys 目前已获得 95% 的手机和 97% 的浏览器的支持。

Passkeys 的最低手机要求是 iOS 16+（iPhone 8 或更新型号，2017 年及以后）和带有 Google Play Services 的 Android 9+（2018 年及以后）。唯一的空白是 2018 年之前的 Android 手机、没有 Google Play Services 的设备以及旧版桌面操作系统（Windows 7/8）。所有主流浏览器都会自动更新，因此桌面覆盖率几乎是普遍的。[0, 1, 2]

Myth 1: Passkey钱包无法跨应用复用

去年，我们在 Porto 上展示了跨应用、跨设备、跨链的 Passkeys。这种用户体验将在未来几天通过我们的账户 SDK 引入 Tempo，这将使由 Passkeys 提供支持的 Tempo 账户感觉像是任何应用程序的单点登录（SSO）。

这通过跨域 iframe 嵌入实现。第三方应用程序嵌入一个来自 wallet.tempo.xyz 的轻量级 iframe。该 iframe 设置了 allow=”publickey-credentials-create; publickey-credentials-get” 权限策略，这是 WebAuthN Level 3 规范支持的。Passkey 流程在 iframe 内部运行，绑定到 tempo.xyz RP ID，因此无论父域托管哪个应用程序，用户现有的钱包凭证都有效。父级通过 postMessage 与 iframe 通信，iframe 处理所有签名。

iframe 方法的强化技术

iframe 方法通过两种技术得到强化：

• 访问密钥（Access Keys）：嵌入式体验可以为第三方应用程序授权一个受限的访问密钥，而不是暴露根签名者。访问密钥具有每个代币的消费限额和过期时间戳，因此父应用程序只能在这些限制内签署交易。
• IntersectionObserverV2 点击劫持预防：在 iframe 渲染 Passkey 提示之前，它使用 IntersectionObserverV2 验证 iframe 是否完全可见且未被覆盖层遮挡。如果恶意父级试图覆盖 iframe 以欺骗用户，我们会检测到并弹出到一个独立的窗口。

Myth 2: Passkey钱包导出、互操作性及域名失效问题

Passkeys 默认通过你的操作系统密钥链（iCloud 密钥链、Google 密码管理器）或密码管理器（1Password 等）同步。如果你登录了 iCloud，你在桌面设备上创建的 Passkey 已经同步到你的手机上。Google 密码管理器在 Android 上也做同样的事情。1Password 等第三方管理器则跨所有平台同步。

但仍然存在一些边缘情况，我们通过 Tempo 账户密钥链 来解决。一个 Tempo 账户就是一个密钥链：

Tempo 账户密钥链

• 根密钥（Root Key）：创建账户的原始密钥（通常是 Passkey）。它拥有完全权限：授权新密钥、撤销密钥、更新消费限额。
• 访问密钥（Access Keys）：由根密钥授权的辅助密钥。它们支持多种签名类型，例如 Secp256k1（标准以太坊密钥）、P256（安全飞地/WebCrypto 密钥）和 WebAuthn（额外的 Passkeys）。每个访问密钥可以有过期时间戳和每个 TIP20 代币的消费限额。

没有登录你的 Apple 账户？只需将你其他设备的 Passkey 添加为访问密钥。你甚至可以添加你的 Ledger、YubiKey 或其他密钥存储作为双因素认证。

如果域名关闭了怎么办？Passkey 凭证本身通过你的操作系统/密码管理器同步——它不会因为网站下线而消失。如果你真的无法再访问 Passkey，访问密钥仍然可以为该账户签署交易。账户存在于链上；密钥只是授权方法。

这与 SSH 的工作方式（多个 authorized_keys）或 OAuth 的工作方式（跨设备的多个刷新Token）直接类似。账户 SDK 将使这一切变得极其易用，就像我们所有其他开发者工具一样。

我对这项功能的未来感到特别兴奋，并可能将其扩展到后量子签名算法，或使用其他保护隐私的机制来授权操作或恢复你的账户，例如使用零知识证明的电子邮件或护照。

Myth 3: Passkeys的交易签名用户体验问题

访问密钥也能解决这个问题！

你使用 Passkey 授权一次访问密钥，然后所有后续交易都由它签署。不再有 Passkey 提示，不再有“通过...登录”的模态框。

想要一个自定义对话框来预览你将在应用程序中签署的内容吗？账户 SDK 将提供该功能。

Passkeys的局限性

Passkeys 有局限性吗？是的，有！

局限性 1: Passkeys在移动端的WkWebViews中无法工作

这是真的。可以通过引导用户打开浏览器来解决。我也期望随着 Passkey 的普及，这将在网络标准层面得到修复。

使用 WebView 或 WKWebView 作为其默认应用内浏览器的移动应用程序（如 X.com）不支持通过 Passkeys 或 U2F（WebAuthN）进行身份验证。我们建议在 Android 上使用 Chrome Custom Tabs，在 iOS 上使用 SFSafariViewController 或 ASWebAuthenticationSession。对于 React Native 移动应用程序，我们推荐 react-native-inappbrowser-reborn 库。

局限性 2: 设备丢失或网站关闭时的恢复问题

如果你没有备份助记词就丢失了它，或者你忘记了应用程序的密码并且忘记了电子邮件的密码，这与此类似。我不知道在任何非托管的身份验证系统中是否能解决这种情况，如果你有解决方案，请告诉我。

展望未来

好的——我希望我已经让你相信 Passkeys 是未来身份验证的趋势。我们在 Tempo 内部一直进行求真辩论，可以同时持有多种观点，并随着对技术的了解更新我们的先验知识，例如，请参阅 Varun 两个月前的帖子，它极大地影响了我对该主题的思考。

许多 Passkey 不兼容问题源于：

1. WebAuthn 公钥创建配置的错误。
2. 客户端和服务器之间凭证序列化不正确，导致某些浏览器/认证器组合无法识别某些值（例如 Firefox + 1password）。

因此，确保开箱即用的最佳实践对于高转化率至关重要。请查看 wevm/webauthx，它为这些情况设置了常规默认值——感谢 @_jxom 和 @awkweb，他们也是 Porto 的幕后主使，Porto 极大地推动了我们对该主题的思考。

我对 Passkeys 的未来还有一件事感到兴奋，那就是 PRF 扩展，它允许你进行端到端加密聊天等。看看 Signal 创始人 Moxie 如何在他的新项目 Confer 中使用它。

希望这对所有读者都有用。

• 原文链接： x.com/gakonst/status/203...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～