---
title: 'Verifiable Passkey: Decentralized Authentication'
url: https://www.emergentmind.com/topics/verifiable-passkey
type: topic
---

# Verifiable Passkey: Decentralized Authentication

A Verifiable Passkey is a decentralized authentication standard that combines FIDO2/WebAuthn-based passkeys and W3C Verifiable Credentials (VCs) to eliminate centralized user-tracking, bypass secure storage constraints, and enable portable, phishing-resistant authentication across uncoordinated relying parties. The Verifiable Passkey framework decouples the attesting root of trust (the VC issuer) from relying parties (verifiers) and avoids the privacy and architectural downsides of both traditional passkey deployments and federated SSO, while retaining the hardware-rooted guarantees of platform authenticators [2512.21663].

## 1. System Architecture and Components

The Verifiable Passkey framework defines four principal roles:

- **User Agent (UA)**: Composed of a browser (WebAuthn client) coordinating with a FIDO2-compatible authenticator (e.g., TPM, secure key store, or roaming security key).
- **Issuer**: A Verifiable Credential issuer that issues a signed VC embedding the passkey's public key, credential ID, and a dedicated PageX URL.
- **PageX**: A static, auditable client-only webpage (served at the Issuer's RP ID origin) responsible for executing WebAuthn calls, specifically `navigator.credentials.create` and `get`. PageX is designed to enforce same-origin binding and avoid any server-side API calls.
- **Verifier (Relying Party)**: Any service accepting a user's Verifiable Passkey Presentation (VPP), verifying the VC signature, and subsequently issuing a FIDO2 challenge via the Issuer's PageX to validate authenticator possession [2512.21663].

Key trust assumptions include:
- Verifiers trust the Issuer's public key (via DID or out-of-band means).
- Authenticators provide FIDO2-compliance and strict RP ID binding.
- PageX's codebase is public and subject to audit, and browsers enforce origin constraints as required by WebAuthn.

This model removes the requirement for per-service key material storage—thereby eliminating the major scaling bottleneck in existing FIDO2 deployments (e.g., hardware tokens restricted to 25–100 stored passkeys) [2512.21663].

## 2. Protocol Flows: Registration, Authentication, and Verification

### Registration / Credential Issuance

1. The user initiates registration with the Issuer.
2. The Issuer generates a randomized challenge and prepares `PublicKeyCredentialCreationOptions` with its domain as `rp.id` and a user handle.
3. The UA redirects the user to PageX with the challenge in the URL.
4. PageX invokes the authenticator to create a new credential (public/private keypair).
5. The authenticator returns `attestationObject` and `clientDataJSON`.
6. PageX submits the attestation result to the Issuer (redirect or postMessage).
7. The Issuer verifies the attestation per WebAuthn Level 2, extracts the credential information, and signs a VC that encodes `"type":"VerifiablePasskey"`, the credential ID, public key, and PageX URL.
8. The user receives and stores this VC in a local or user-controlled wallet [2512.21663].

### Authentication / Challenge–Response

1. The user uploads the VC (optionally within a Verifiable Presentation) to the Verifier.
2. The Verifier verifies the VC’s signature, extracts relevant keying material and the PageX URL.
3. The Verifier generates a new challenge and redirects the user to PageX, parameterized with the challenge.
4. PageX executes `navigator.credentials.get`, restricting `allowCredentials` to the credential ID from the VC.
5. The authenticator produces a FIDO2 assertion (signature over challenge and authenticator data).
6. PageX returns the assertion to the Verifier, which validates the signature against the VC’s embedded public key.
7. If the assertion and VC both verify, the user is authenticated [2512.21663].

### Table: Registration and Authentication Steps

| Phase            | Participant | Core Step                                                          |
|------------------|-------------|--------------------------------------------------------------------|
| Registration     | Issuer      | Issues challenge, prepares credential creation options              |
| Registration     | PageX       | Requests FIDO2 credential from authenticator (attestation)          |
| Registration     | Issuer      | Verifies attestation, issues VC containing credential metadata      |
| Authentication   | Verifier    | Verifies VC, challenges via PageX                                  |
| Authentication   | Authenticator| Signs challenge, produces assertion                               |
| Authentication   | Verifier    | Verifies assertion and authenticates user                          |

## 3. Cryptographic Primitives and Formal Properties

The framework leverages the following cryptographic mechanisms:

- **Authenticator Keypairs**: $(sk, pk) \leftarrow GenKeypair(1^\lambda)$. Usually ECDSA (P-256) or EdDSA (Ed25519) represented via COSE.
- **FIDO2 Signature**: $\sigma \leftarrow Sign(sk, challenge \| authData \| clientDataJSON)$, with $\operatorname{Verify}(pk, challenge \| authData \| clientDataJSON, \sigma) \stackrel{?}{=} \text{true}$.
- **VC Signature**: $\pi_{VC} \leftarrow Sign_{Issuer}(sk_{Issuer}, VC_{payload})$; $\operatorname{Verify}_{Issuer}(pk_{Issuer}, VC_{payload}, \pi_{VC}) \stackrel{?}{=} \text{true}$.
- **Zero-Knowledge Proofs**: The architecture allows for future augmentation with ZK proofs $\pi_{ZK} \leftarrow \mathtt{ZKProve}(\text{“I know } sk \text{ with } pk = g^{sk}\text{”}, sk)$; not implemented in the canonical protocol [2512.21663].

Formal security goals (sketched in [2512.21663]):

1. **Unforgeability of FIDO2 assertions**: Forgery implies compromise of the authenticator’s underlying signature scheme.
2. **Unforgeability of the VC**: Compromise would require forging the Issuer’s signing key (EUF-CMA).
3. **Privacy and Unlinkability**: Issuers cannot observe authentication events (no server-side calls from PageX/Verifier to Issuer). Relying parties are unable to link the user’s authentications across domains.

Reduction arguments demonstrate that user impersonation—without the authenticator’s private key or a valid VC from the Issuer—constitutes either a successful forgery against the digital signature scheme (COSE/JWS) or the authenticator itself [2512.21663].

## 4. Comparison to Existing Authentication Models

Verifiable Passkey addresses several principal limitations of mainstream FIDO2 passkeys and federated SSO:

| Property                      | FIDO2 Passkeys           | Federated SSO                 | Verifiable Passkey            |
|-------------------------------|--------------------------|-------------------------------|-------------------------------|
| Phishing resistance           | Yes                      | Yes (depends on IdP/flow)     | Yes                           |
| Unique per-RP key storage     | Yes (per RP)             | No (reuses via IdP)           | No (reusable across verifiers)|
| Secure storage requirement    | Per RP (e.g., ≤100)      | Single per IdP                | Single per Issuer             |
| Central login logs/user tracking | No                         | Yes                           | No                            |
| Decentralized                 | No                       | No                            | Yes                           |
| WebAuthn/FIDO2 compliance     | Yes                      | Partially                     | Yes                           |
| Privacy/unlinkability         | Yes (local)              | No (IdP tracking)             | Yes                           |

- FIDO2 passkeys are strictly bound per relying party, limited by hardware storage.
- Federated SSO reduces key creation but introduces privacy risks as the IdP observes all authentications.
- Verifiable Passkey allows reuse of a single passkey for arbitrarily many verifiers, independent of storage limits and without privacy leakage via a central authentication intermediary. The solution remains fully compliant with WebAuthn, and privacy is preserved as the Issuer has neither a role nor observational capacity in authentication events [2512.21663].

## 5. Security, Privacy, and Threat Model

Adversarial capabilities considered include eavesdropping, phishing, replay, as well as PageX or Verifier compromise. The assumption is that FIDO2 authenticators are tamper-resistant and do not leak secret material. The design confers the following core properties:

- **Phishing Resistance**: Origin checks, enforced by the authenticator and browser, ensure domain binding on FIDO2 challenges.
- **Key Non-Extractability**: The authenticator’s private key remains sealed and non-exportable.
- **Unlinkability/Non-Tracking**: No central server aggregates login data. Issuers are never contacted during authentication flows.
- **Replay and Cloning Protection**: Per-challenge randomness and monotonic signature counters protect against replay and duplicated tokens.
- **Resistance to Offline Attack**: No server possesses secrets that would allow for brute-force or offline attacks. Live authenticator verification is required for every assertion [2512.21663].

## 6. Implementation, Performance, and Operational Considerations

A reference implementation, comprising a Python-based Issuer/Verifier suite and client-only PageX instance hosted on GitHub Pages, demonstrates feasibility:

- **Performance Benchmarks**:
  - `makeCredential` or `getAssertion` (via CTAP): 80–120 ms on contemporary hardware.
  - VC signature validation (JWS/JSON-LD): 5–10 ms.
  - Total end-to-end authentication: 200–300 ms in low-latency settings.
- **Storage Footprint**: A single VC JSON (2–3 KB) per user, plus the authenticator’s native credential state.
- **Base64 Encoding**: Byte fields in the VC JSON are prefixed with "base64_" for correct serialization.
- **Public Key Distribution**: Issuer public keys may be distributed via standard DID endpoints or OIDC metadata [2512.21663].

**Revocation** is achieved via a published VC status list (SID/CRL), with verifiers required to check VC validity against this resource. **Recovery** mandates re-enrollment with the Issuer should the authenticator be lost, yielding a new VC bound to a fresh keypair.

## 7. Applications and Use Cases

An exemplar application involves government-issued Verifiable Passkeys for age-verification (e.g., “age ≥ 21”). The lifecycle follows:

1. The government (Issuer) creates a VC stating the age attribute, credential ID, public key, and PageX URL.
2. The user stores this VC in a digital wallet.
3. Upon registering for an online service, the user presents the VC; the Verifier confirms the government’s signature and performs a fast FIDO2 challenge via government-issued PageX.
4. At no point does raw PII or interaction with the government servers occur during authentication—the Verifier only gains cryptographic assurance of the stated attribute [2512.21663].

This model supports any scenario where privacy-preserving, portable, and strongly authenticated credentials are required, eliminating most attack surfaces associated with passwords, federated SSO, and local private key management.

---

For comprehensive details, including security reductions, implementation design, and cryptographic protocol sketches, see "Verifiable Passkey: The Decentralized Authentication Standard" [2512.21663]. Foundational context regarding FIDO2/WebAuthn passkey lifecycle, attestation procedures, and typical implementation pitfalls is elucidated in [2508.11928] and [2507.09022].

Source: https://www.emergentmind.com/topics/verifiable-passkey