Chapter 3: Why Standards Matter
What you'll learn:
- Why interoperability is the hardest problem in digital identity
- What happened when SSI was built without agreed standards
- What eIDAS 2.0 mandates, and why it changes everything
- The three standards this book is built around: OID4VCI, OID4VP, and SD-JWT
The passport thought experiment
A physical passport works everywhere. You can present a British passport at an airport in Japan, and the officer will recognise it as valid — not because Japan has a special API connection to the UK Passport Office, but because there is an international standard (ICAO Document 9303) that defines exactly what a passport looks like, how it is signed, and how it is verified. Every country that joins the system agrees to the same format.
Now imagine if every country designed its own passport format. Different sizes, different fields, different security features, different verification procedures. An officer checking a foreign passport would need to know the rules for every country in the world. Border crossings would grind to a halt.
This thought experiment describes exactly what happened with early digital identity. Everyone built their own system. The result was not interoperability — it was islands.
The fragmentation era
The first generation of SSI technology was built with good intentions but without global coordination. Different communities created different credential formats, different transport protocols, different ledger systems, and different DID methods — over 100 different DID methods were registered in the W3C DID registry.
A credential issued by a system using Hyperledger Indy and DIDComm could not be read by a system using Ethereum and a different transport. A wallet built for one ecosystem could not present credentials to a verifier in another.
This was not a theoretical problem. In real pilot projects — for digital vaccination certificates, for digital driving licences, for employee identity cards — interoperability between pilot programmes in different cities, let alone different countries, was a persistent and expensive failure.
Business significance: Fragmentation kills adoption. If enterprises need to choose which SSI ecosystem to join — knowing they will be locked out of others — they will delay the decision indefinitely. Standards break this deadlock.
What the EU decided
In 2021, the European Commission proposed a revision to the existing eIDAS regulation (Electronic Identification and Trust Services). The resulting legislation — commonly called eIDAS 2.0 — was politically agreed in 2023 and is being implemented across EU member states through 2026.
The regulation makes three significant decisions:
1. Every EU citizen will have a digital wallet. Member states are required to offer a European Digital Identity (EUDI) wallet to all citizens and residents. This wallet must be accepted by all public services and by large private platforms within the EU.
2. The wallet will use specific open standards. Rather than leaving the technical choice to each member state, eIDAS 2.0 mandates specific standards. The Architecture and Reference Framework (ARF) — the technical specification published alongside the regulation — names:
- OID4VCI (OpenID for Verifiable Credential Issuance) for issuing credentials into the wallet
- OID4VP (OpenID for Verifiable Presentations) for presenting credentials from the wallet
- SD-JWT (Selective Disclosure JSON Web Token) as the primary credential format
- ISO/IEC 18013-5 mdoc as a secondary credential format (primarily for driving licences)
3. Private companies must accept the wallet. Banks, telecoms, large platforms, and other regulated entities must accept the EUDI wallet for identity verification within the EU. This is not optional.
This is a significant departure from how standards normally develop. Rather than waiting for the market to converge, the EU has legislated the destination. For anyone building digital identity systems in or for Europe, these standards are no longer optional — they are the law.
Why these particular standards
The standards mandated by eIDAS 2.0 were not invented by the EU. They come from two existing standards bodies:
OpenID Foundation — the organisation that maintains the OAuth and OpenID Connect specifications. OID4VCI and OID4VP are extensions of existing OAuth 2.0 mechanisms. Every major programming language already has libraries for OAuth. Every developer already understands token exchanges, redirect URIs, and HTTP flows. OID4VCI and OID4VP slot into this existing mental model.
IETF — the Internet Engineering Task Force, which maintains JWT (JSON Web Tokens) and many other foundational internet standards. SD-JWT is an IETF standard (RFC 9278 extended by the SD-JWT specification) that extends JWT with selective disclosure. Any developer who has worked with JWTs — which is most backend developers — can understand SD-JWT with a short extension of existing knowledge.
The choice was deliberate. These standards use familiar tools. They work over standard HTTPS. They do not require blockchain. They do not require a mediator service. They work with existing OAuth infrastructure. This dramatically lowers the barrier to adoption compared to earlier SSI technology.
The three standards in brief
This book is built around three standards. Here is a one-paragraph summary of each — enough context to follow the rest of Part 1. Full chapters are dedicated to each in Part 3.
OID4VCI — OpenID for Verifiable Credential Issuance The protocol by which an issuer (e.g., a government) delivers a signed credential to a wallet. The wallet scans a QR code containing a credential offer URL. It then makes a series of standard HTTPS calls — exchanging a pre-authorisation code for an access token, then using that token to request the credential. The result is a signed SD-JWT stored in the wallet.
OID4VP — OpenID for Verifiable Presentations The protocol by which a wallet presents one or more credentials to a verifier (e.g., an airport). The verifier publishes a presentation request specifying exactly which credential types and attributes it needs. The wallet selects matching credentials, the user approves, and the wallet sends a signed response. The verifier checks the cryptographic signature without contacting the issuer.
SD-JWT — Selective Disclosure JSON Web Token The credential format. A regular JWT signed by the issuer, extended with a mechanism that allows individual claims to be concealed at issuance and selectively revealed at presentation. The holder cannot forge claims (they are signed), but can choose which signed claims to reveal. The verifier sees only what was revealed, and can confirm each revealed claim is genuine.
Together, these three standards describe the complete lifecycle of a digital credential:
What this means for builders
If you are building a system that issues or verifies digital credentials in the EU — or that wants to interoperate with EU systems — you do not have a choice about which standards to use. OID4VCI, OID4VP, and SD-JWT are the mandated path.
But this is not a constraint — it is a gift. These standards are well-specified, backed by major standards bodies, and supported by existing tooling. You do not need to invent anything. You need to implement what is already specified.
| Standard | Maintained by | Purpose | Replaces |
|---|---|---|---|
| OID4VCI | OpenID Foundation | Credential issuance | Proprietary issuer APIs, CHAPI |
| OID4VP | OpenID Foundation | Credential presentation | DIDComm presentation exchange |
| SD-JWT | IETF | Credential format | AnonCreds, JSON-LD VC, JWT-VC |
| did:web | W3C / DIF | Trust anchor | Blockchain-based DID methods |
The rest of this book shows you what that looks like.
Summary
Digital identity without standards produces fragmentation: every system is an island, interoperability is impossible, and adoption stalls. The EU's eIDAS 2.0 regulation resolves this by mandating specific open standards — OID4VCI, OID4VP, and SD-JWT — for all European digital identity wallets. These standards use familiar web technology (HTTPS, OAuth 2.0, JWT) and remove the need for blockchain or proprietary infrastructure. For anyone building in this space, they are now the baseline.
Part 2 goes deeper into why this stack was chosen — including an honest look at what came before it.
Next: Part 2 — The Stack