Introduction
The problem
Section titled “The problem”Centralized Identity and Access Management (IAM) stores passwords and credentials on organizational servers — a model that turns those servers into high-value targets and exposes users to phishing, brute-force attacks, credential reuse, and mass data breaches.
Two technologies have emerged to address the structural weakness:
- Self-Sovereign Identity (SSI) decentralizes credential storage. Users hold their credentials in personal wallets and present them peer-to-peer to verifiers, using cryptographic proofs based on Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). The model eliminates the central honeypot but introduces UX friction: every user must install, configure, and never lose access to a wallet application.
- FIDO eliminates passwords by replacing them with public-key cryptography backed by hardware. Private keys live in user devices (Touch ID, security keys, Passkeys) and never leave them, so phishing and man-in-the-middle attacks become structurally infeasible. But FIDO is an authentication primitive — it has no concept of issuers, no attribute model, no notion of a verifiable claim.
Each technology covers half the problem. Combining them naively — adding FIDO authentication on top of a traditional SSI wallet, or adding attribute claims to FIDO — doesn’t dissolve the original tension. SSI deployments still die on wallet-install friction; FIDO deployments still can’t carry portable attestations.
What FIDO4VC is
Section titled “What FIDO4VC is”FIDO4VC is a protocol that decomposes the wallet into two functions that prior designs always fused:
- Authority — who can present a credential — is bound to the user’s FIDO authenticator. The private key never leaves the device’s secure element.
- Custody — where credentials are stored at rest — lives in a cloud wallet service.
The cloud wallet alone cannot present a credential. Even with full database access, an attacker gets only inert artifacts; a presentation requires a fresh FIDO assertion from the actual user. This is the security property no prior SSI design has — and it’s what makes putting credentials in the cloud architecturally acceptable in the first place.
The protocol is fully compatible with existing W3C and OpenID standards. Issuance uses OpenID4VCI. Presentation uses OpenID4VP with the ldp_vp proof type. The proof itself is a standard W3C Data Integrity proof under a new cryptosuite (fido4vc-jcs-2026) that maps a WebAuthn assertion into a verifiable proof value. Verifiers only need to add support for the one new cryptosuite — every other layer is off-the-shelf.
Who it’s for
Section titled “Who it’s for”The protocol targets deployments where the wallet-app install step has been the adoption bottleneck:
- Public-sector services — citizen credentials issued once, used rarely, across years and device generations
- Enterprise B2B — contractor and partner access without IdP provisioning
- High-stakes regulated credentials — banking, healthcare, identity documents where on-device hot-wallet risk is unacceptable to regulators
- Agentic delegation — issuing scoped, time-limited authority to AI agents acting on a user’s behalf
Implementers, integrators, and architects looking to evaluate or adopt FIDO4VC will find the architecture and specification sections most useful. Decision-makers comparing it against alternatives may want to start with Use Cases.
What’s distinctive
Section titled “What’s distinctive”Compared to traditional SSI deployments and to FIDO-alone authentication, FIDO4VC offers a small set of structural properties no other architecture combines:
| Property | Why it matters |
|---|---|
| Zero install — works in any WebAuthn browser | Removes the single largest historical SSI adoption barrier |
| OS-mediated Passkey sync — iCloud, Google, Microsoft | Recovery and cross-device portability come free; no seed phrase, no vendor backup |
| Hardware-bound private key + cloud-held credential | A breach of the cloud wallet does not yield presentable VPs |
| Recoverable across device generations | Your Passkey on the phone you buy in 2031 still unlocks credentials issued in 2026 |
| Familiar OS-native UX primitive | Face ID / Touch ID / security-key prompt; users already do this daily |
| Cross-device by default | WebAuthn’s hybrid transport (“show QR on laptop, sign on phone”) is built in |
These are the properties everything else in this documentation builds on.
Where to next
Section titled “Where to next”- Background — quick recap of SSI, FIDO, OpenID4VC, and walt.id
- Architecture — system model, layers, and trust boundaries
- Specification — normative cryptosuite definition