Authentication proves a credential. Presence proves participation.
A passkey proves a trusted authenticator was used. It does not prove the authorized person is participating in this specific action, right now.
What each layer actually establishes
A password establishes that someone knew a secret at some point. A passkey is far stronger — it proves a specific authenticator was present and unlocked — but both answer a question about a credential, not about a person's participation in a particular action.
Presence binds the check to the action. The WebAuthn assertion's challenge is the session nonce, and that nonce commits to a SHA-256 digest of the action context — amount, intent, actor, target. A signature collected for one action cannot be spent on another, because the digest would not match.
That binding is verified server-side. The client's self-reported hardware block is discarded outright rather than cross-checked, so a forged claim cannot influence the verdict even when it happens to agree with the truth.
Check it yourself
The artifacts behind this page
- The assertion challenge is the session nonce, which commits to the action digest.How action binding works →
- Client-supplied anchors are replaced with server-verified ones before the gate evaluates.Threat model →
What this page does not claim
Limits
- Presence does not establish who someone is in the first place. It re-establishes that the enrolled, authorized person is the one acting now. Identity onboarding remains your existing process.