Passkeys are the future of authentication and authorization without passwords.
Passkeys reduce sign-up / sign-in time, reduce fraud and increase conversion in commerce (see case studies here). Don’t hear it from me, hear it from Apple, Google and Paypal.
Passkeys are also the future of web-native self-custodial crypto wallets without intermediaries. They work with YubiKeys, making them excellent for enterprise grade security.
Many of you experienced this through the Tempo Mainnet and Machine Payments Protocol launch. The onboarding experience is slick, fast, butter smooth, and obviates the need for chrome extensions, mobile apps, and seed phrases – things that everybody dislikes in the crypto world.
If you don’t believe this, just run “install tempo.xyz/SKILL.md” in your agent, and ask it to onboard you.
While there are historical rough rough edges around correctly integrating Passkeys, they are solvable engineering problems, a lot of which we have solved at @tempo. We encountered a lot of these problems in 2024-2025, when we built Porto. This not new terrain for our team.
I will now clear some myths about Passkeys that people are repeating without having intimately worked with this very powerful technology.
A lot of this is technical and not for everybody, and your 1-line takeaway should be “Passkeys are the future”. If you’re technical, feel free to chime in to the conversation and let’s have an open-ended, truth-seeking debate.
Please engage thoughtfully.
Myth 0: Passkeys are not adopted by browsers and phones.
Passkeys are supported by 95% of phones and 97% of browsers today.
The minimum phone requirements for passkeys is iOS 16+ (iPhone 8 or newer, 2017+) and Android 9+ with Google Play Services (2018+). The only gaps are Android phones <2018), devices without Google Play Services, and legacy desktop OS (Windows 7/8). All major browsers auto-update so desktop coverage is near-universal. [0, 1, 2]
Myth 1: Passkey wallets cannot be reused across applications.
We demonstrated cross app, cross device, cross-chain passkeys last year on Porto. This UX is coming to Tempo in the coming days with our Account SDK, which will make the Tempo Account powered by Passkeys feel like SSO for any application.
This works via cross-origin iframe embedding. A third-party app embeds a thin iframe from wallet.tempo.xyz. The iframe has the allow=”publickey-credentials-create; publickey-credentials-get” permission policy set, which the WebAuthN Level 3 spec supports. The passkey ceremony runs inside the iframe, bound to the tempo.xyz RP ID, so the user’s existing wallet credential works, regardless of which parent domain hosts the app. The parent communicates with the iframe via postMessage, and the iframe handles all the signing.
The iframe approach is hardened with two techniques:
- Access Keys (see below): The embedded experience can authorize a scoped Access Key for the third-party app, instead of exposing the root signer. The Access Key has per-token spending limits and an expiry timestamp, so the parent app can only sign transactions within those bounds.
- IntersectionObserverV2 Clickjacking Prevention: Before the iframe renders a passkey prompt, it uses IntersectionObserverV2 to verify the iframe is fully visible and not obscured by an overlay. If a malicious parent tries to cover the iframe to trick the user, we detect it and pop out to a standalone window instead.
Myth 2: Passkey wallets cannot be exported. Passkey Interoperability is broken. Passkeys are not usable if the domain you registered a passkey with is down.
Passkeys sync by default via your OS keychain (iCloud Keychain, Google Password Manager) or password manager (1Password etc.). If you're logged into iCloud, your passkey created on the desktop is already on your phone. Google Password Manager does the same on Android. Third-party managers like 1Password sync across every platform.
But there’s still edge cases, which we answer with the Tempo Account Keychain. A Tempo Account is a keychain:
- Root Key: The original key that created the account (typically a passkey). It has full authority: authorizing new keys, revoking keys, updating spending limits.
- Access Keys: Secondary keys authorized by the Root Key. These support multiple signature types such as Secp256k1 (standard Ethereum keys), P256 (secure enclave / WebCrypto keys), and WebAuthn (additional passkeys). Each Access Key can have an expiry timestamp and per-TIP20 token spending limits.
Not logged into your Apple account? Just add your other device’s Passkey as an access access key. You can even add your Ledger, YubiKey, or other keystore if you want as 2FA.
What if the domain shuts down? The passkey credential itself is synced via your OS/password manager - it doesn't vanish if a website goes offline. And if you truly cannot access the passkey anymore, the access key can still sign transactions for that account. The account lives on-chain; the keys are just authorization methods.
This is directly analogous to how SSH works (multiple authorized_keys) or how OAuth works (multiple refresh tokens across devices). The Account SDK will make all this extremely easy to use, like all our other developer tools.
I am particularly excited about the future of this feature, and potentially extending it to Post Quantum signature algorithms, or using other privacy-preserving mechanisms for authorizing an action or recovering your account, e.g. your e-mail or passport using zero knowledge proofs.
Myth 3: Passkeys force “Sign in with example.com” UX to sign a transaction, which is confusing for users.
Access Keys also solve this!
You authorize an Access Key once with your passkey, and then every subsequent transaction is signed by it. No more passkey prompts, no more "Sign in with" modals.
Want a custom dialog for previewing what you’ll sign in the app? The Account SDK will provide that functionality.
Are there limitations to Passkeys? Yes there are!
Limitation 1: Passkeys don’t work in WkWebViews on mobile.
This is true. This can be worked around by guiding the user to open their browser. I also expect this will be fixed at the web standards level as Passkey adoption takes off.
Mobile apps (like X.com) using WebView or WKWebView as their default in-app browser do not support authentication via Passkeys or U2F (WebAuthN). We recommend using Chrome Custom Tabs on Android and SFSafariViewController or ASWebAuthenticationSession for iOS. For React Native mobile apps, we recommend the react-native-inappbrowser-reborn library.
Limitation 2: What if you are not logged in to iCloud/1Password, you do not add an access key, and you lose access to your device or the website shuts down?
This is similar to losing your seedphrase without backing it up anywhere, or if you forgot your password in an application AND you forgot your e-mail’s password. I do not know if this is a case that can be solved in any auth system that is also non-custodial, if you know a solution, let me know.
So what’s next?
OK - I hope I have convinced you about Passkeys as the future of auth at this point. We do truth seeking debates all the time internally at Tempo, and can hold a lot of perspectives at the same time and update our priors as we learn more about technology e.g. see Varun’s post from 2 months ago which influenced a lot of my thinking on the topic.
A lot of the passkey incompatibility issues stem from:
1. Misconfiguration on the WebAuthn public key creation configuration.
1. Not serializing credentials between client and server properly, that causes certain browser/authenticator combinations downstream to not pick up certain values (ie. Firefox + 1password).
So ensuring best practices out of the box is important for high conversation rates. Check out wevm/webauthx which sets up conventional defaults for these cases - h/t @_jxom @awkweb, who are also the masterminds behind Porto which drove a lot our thinking on the topic.
There is one more thing I am excited about the future of Passkeys, the PRF Extension which lets you do E2E encrypted chat and more. See how Moxie, founder of Signal using it in his new project, Confer.
I hope this was useful to whomever reads this.
Try out Tempo, MPP, and let me know what you think. Ask your agent to install tempo.xyz/SKILL.md, and take you on a wild journey.
We’re also hiring stellar talent. Use the MPP Email services if you want me to for sure take a look.
Back to building.