WebAuthn & Passkeys
One-line relationship: WebAuthn is the browser API; passkeys are the product built on it. FIDO2 is the umbrella spec pairing WebAuthn (browser ↔ relying party) with CTAP (browser ↔ authenticator). This is C1 — the front door — and the direct web analog of the mobile app’s biometric-gated enclave key.
What it is
WebAuthn replaces “prove you know a secret” with “prove you hold a private key,” using standard public-key cryptography instead of a shared password:
- Registration: the relying party (your bank) asks the browser to create a credential. The authenticator (Face ID, Windows Hello, a hardware security key) generates a key pair, keeps the private key non-extractable, and returns the public key + a credential ID.
- Authentication: the RP sends a random challenge; the authenticator signs it with the private key; the RP verifies the signature against the stored public key.
The password is gone entirely — there’s nothing to phish, breach in a database dump, or reuse across sites.
Why it resists phishing (the origin binding)
Every credential is scoped to a Relying Party ID (RP ID) — a domain — at creation time. The browser enforces that an authenticator will only sign a challenge for the origin the credential was created under. A look-alike phishing domain (bank-secure.example instead of bank.example) simply can’t obtain a valid signature: the browser won’t even offer the credential to the wrong origin. This is a structural property, not user vigilance — the first meaningful gap this portal has to close relative to the mobile app’s hardware trust.
Phishing-resistant is not phishing-proof. A passkey defeats credential replay and look-alike domains. It does not defeat malware already running with the user’s privileges on an already-compromised, already-unlocked device — there the browser session itself is the attack surface, which is why C2 (request integrity) and C6 (device/malware intelligence) still matter even after passkeys are in place.
Synced vs device-bound
- Synced passkeys (iCloud Keychain, Google Password Manager) replicate the private key across a user’s devices via the platform’s own encrypted sync. Convenient — a new phone has your passkeys immediately — but the assurance level is “as strong as the platform account,” not “this one physical device.”
- Device-bound passkeys never leave the authenticator that created them (typical for hardware security keys, and some enterprise-managed platform keys). Higher assurance, worse recovery story — lose the device, lose the credential.
A bank’s risk tier decides which to require or accept; PSD2/SCA-grade flows often prefer device-bound for the highest-value actions.
Try it — a real ceremony
What to take to the client
Passkeys aren’t a UX nicety layered on top of the old login — they eliminate the entire class of credential-replay and look-alike-phishing attacks by construction. What they don’t do is replace C2 (does every subsequent request still come from that bound session?) or C6 (is this device compromised right now?). Passkeys own the login moment; the rest of the stack owns everything after it.