On passkeys

For a technical buyer, passkeys are the first comparison worth making — so let us make it plainly. Passkeys, built on WebAuthn and the FIDO2 stack, are the best thing to happen to logging in for a long time. Ydentifi is not an alternative to them. It does a different job, and the two compose.

What passkeys solve#

A passkey is a public–private key pair bound to a website’s origin, with the private key held in the device’s secure hardware and unlocked by a local biometric or PIN. Registration creates the pair; signing in proves possession of the private key. Two properties make this a genuine advance:

• Phishing resistance built in. The credential is scoped to the origin that created it, so a look-alike domain cannot elicit a usable signature. It is the property that matters most — see On passwords for why phishing is the elephant in the room. Ydentifi does not bind a login to a site this way. Its resistance comes from the action: the phone signs the exact details the user saw.
• No shared secret to steal. There is no password sitting on a server to breach, reuse, or leak. The private key never leaves the device.

What a passkey attests is precise: the holder of this device, unlocked locally, is the account-holder who registered. That is exactly what a login needs, and passkeys do it better than a password ever could.

Where the line is#

A passkey proves who is returning. It does not, by itself, prove what they are agreeing to. Three gaps open past the login line:

• No action binding. A WebAuthn assertion signs a server-issued challenge — a nonce — not the human-readable details of an operation. It says “the account-holder is present,” not “the account-holder approved a €4,200 transfer to this account.” Transaction authorization existed only as an optional WebAuthn extension and is not what deployed passkey login does; nothing in the usual ceremony ties the signature to the stakes.
• One assurance level. A passkey unlock is a passkey unlock. There is no built-in notion that this action needs a stronger check than that one — say, a biometric with no passcode fallback once the amount crosses a threshold. Step-up is left to the relying party to invent.
• Someone else’s infrastructure. Passkeys sync through the platform’s cloud — iCloud Keychain, Google Password Manager — and their recovery, device list and account model belong to that ecosystem, not to you. For a bank, or an air-gapped deployment, a verifier and trust store that live inside a consumer cloud is a sovereignty problem, not a feature.

None of this is a criticism of passkeys. It is simply the boundary of the job they were designed for: proving identity at the door, not adjudicating each decision inside.

Login and approval, together#

The useful model is enabler, not alternative. Let passkeys do what they are best at — passwordless, phishing-resistant login. Then, at the moments that carry risk, add an approval a passkey does not give you:

• The signature covers the action. Ydentifi’s device signs over the exact on-screen details of the operation — amount, destination, the sentence the user read — so an altered request will not verify. A relay can pass a request on, but it cannot change what the user approves. The proof is about the decision, not merely the presence. See The ceremony.
• Assurance is chosen per action. You pick the level — device unlock or biometric only — and add a location check or number matching where the action needs it, per action, not once per login. See Factors & levels.
• You own the verifier. The trust chain is your PKI, the server runs on your infrastructure, and no end-user data leaves it. There is no consumer cloud in the authentication path — see What is Ydentifi.

So the framing is not passkeys versus Ydentifi. It is passkeys at the door and Ydentifi at the decisions that matter — a login layer and a high-assurance action-authorization layer, doing two different jobs well. If you already use passkeys, keep them; Ydentifi picks up exactly where their line stops.