Skip to content
FIDO4VC FIDO4VC

Background

FIDO4VC composes well-established standards rather than inventing new ones. This page is a quick reference for readers less familiar with one or more of them. Skip if you’re already at home with SSI, FIDO2/WebAuthn, OpenID4VC, and walt.id.

Self-Sovereign Identity (SSI)

Section titled “Self-Sovereign Identity (SSI)”

SSI is a decentralized model for digital identity. Instead of relying on a central identity provider, users hold their own credentials and present them peer-to-peer.

Three core primitives:

  • Decentralized Identifier (DID) — a globally unique, resolvable identifier under user control. FIDO4VC uses did:jwk, which embeds a JSON Web Key directly into the DID — no ledger, no DNS, no central registry. The DID resolves deterministically to the public key it encodes.
  • Verifiable Credential (VC) — a cryptographically signed attestation issued by a trusted party. The credential subject is identified by a DID; the issuer signs the claim with their own key.
  • Verifiable Presentation (VP) — a wrapper around one or more VCs, signed by the holder to prove possession and control. Verifiers validate the VP’s signature, the embedded VCs, and the binding between holder and subject.

In a traditional SSI deployment, all of this lives in a wallet app on the user’s device. FIDO4VC keeps the credentials in the cloud but pushes the signing operation back to the user’s FIDO authenticator.

FIDO2 and WebAuthn

Section titled “FIDO2 and WebAuthn”

FIDO2 is the family of standards that enables passwordless authentication using public-key cryptography. WebAuthn is the W3C API that exposes FIDO2 authenticators (Passkeys, security keys, platform biometrics) to web applications.

Key properties:

  • Private keys never leave the authenticator. Generated in a secure element, exposed only as signing operations.
  • User presence and verification are enforced by the hardware (biometric, PIN, or token press). The authenticator refuses to sign without it.
  • Origin-bound by default. Each relying-party origin gets a distinct key pair, preventing cross-site correlation.
  • Sync across devices (Passkeys). Apple, Google, and Microsoft sync user-verifying Passkeys across devices signed into the same OS account.

FIDO4VC treats the WebAuthn signing primitive as a black box: the protocol designs a custom challenge (the canonicalized VP hash) and embeds the resulting WebAuthn assertion (authenticatorData, clientDataJSON, signature) into the VC Data Integrity proof.

OpenID for Verifiable Credentials (OpenID4VC)

Section titled “OpenID for Verifiable Credentials (OpenID4VC)”

The OpenID Foundation has standardized two protocols for VC exchange:

  • OpenID4VCI — Issuance. Defines how an issuer offers a credential to a holder and how the holder’s wallet redeems the offer. FIDO4VC uses the Pre-Authorized Code flow with the ldp_vp proof type, where the wallet proves control of a DID by signing a Verifiable Presentation that the issuer’s response binds to.
  • OpenID4VP — Presentation. Defines how a verifier requests credentials and how a holder presents them. Supports cross-device (QR-based) and same-device flows. FIDO4VC sits within OpenID4VP’s ldp_vp proof type, with no protocol-level changes.

The full FIDO4VC value comes from how these flows compose with the FIDO authenticator and the cloud wallet — the protocols themselves are unmodified.

JSON Canonicalization Scheme (RFC 8785)

Section titled “JSON Canonicalization Scheme (RFC 8785)”

VC Data Integrity proofs require canonicalization — a deterministic byte-level representation of the document being signed. Without it, equivalent JSON encodings (different key order, whitespace, number formatting) would produce different hashes and break signature verification.

FIDO4VC uses RFC 8785 (JSON Canonicalization Scheme, JCS) — a relatively simple canonicalization that:

  • Sorts object keys lexicographically
  • Normalizes number formatting per ECMAScript Number.toString
  • Escapes strings minimally
  • Emits no whitespace

The cryptosuite name fido4vc-jcs-2026 advertises this choice. Verifiers and signers must use bit-identical JCS implementations or signatures won’t verify.

W3C Verifiable Credential Data Integrity

Section titled “W3C Verifiable Credential Data Integrity”

W3C VC Data Integrity defines a pluggable proof-type system for VCs and VPs. The proof carries:

  • A type (DataIntegrityProof)
  • A cryptosuite identifier (the name we register: fido4vc-jcs-2026)
  • verificationMethod (DID pointing to the signer’s public key)
  • proofPurpose (e.g., authentication)
  • proofValue (the actual signature material)

Each cryptosuite specifies the canonicalization, hashing, and signing algorithm to apply. FIDO4VC adds fido4vc-jcs-2026 to this registry — see the spec for full details.

walt.id

Section titled “walt.id”

walt.id is an open-source SSI infrastructure providing wallet, issuer, and verifier APIs in Kotlin/JVM. FIDO4VC’s reference deployment uses walt.id for the cloud-wallet, issuer, and verifier components.

walt.id provides:

  • A Wallet API managing DIDs, credentials, and external-signature exchange flows (the wallet prepares unsigned VPs and accepts the FIDO-signed result for submission)
  • An Issuer API issuing credentials with configurable proof types
  • A Verifier API validating VPs through a pluggable policy framework

FIDO4VC’s integration touches walt.id’s policy system (registers the signature_ld-vp policy that calls our verifier sidecar), issuer config (ldp_vp supported with fido4vc-jcs-2026), and wallet-API external-signature flow. See the Integration Guide for details.

Where to next

Section titled “Where to next”