Verifiable Passkey: Decentralized Authentication

• Verifiable Passkey is a decentralized authentication standard combining FIDO2 passkeys with Verifiable Credentials to enable secure and privacy-focused access.
• It decouples the attesting authority from relying parties, eliminating centralized tracking and mitigating key storage bottlenecks.
• The framework leverages FIDO2 protocols and robust cryptographic techniques to ensure phishing resistance, non-linkability, and hardware-rooted security.

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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) (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

Formal security goals (sketched in (Mitra et al., 25 Dec 2025)):

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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 (Mitra et al., 25 Dec 2025).

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" (Mitra et al., 25 Dec 2025). Foundational context regarding FIDO2/WebAuthn passkey lifecycle, attestation procedures, and typical implementation pitfalls is elucidated in (Tran et al., 16 Aug 2025) and (Kayali et al., 11 Jul 2025).