SD-JWT VC and OpenID4VP: The Protocols Behind the EUDI Wallet

Most of the conversation around the EUDI Wallet sits at the political and organisational level: member-state provisioning by the end of 2026, registration duties, acceptance deadlines. But anyone who actually wants to accept the wallet eventually faces a technical question: how exactly do I verify that a presented attribute is genuine, valid and sufficient for my purpose? This article looks at the verification side and the building blocks that come together there.

Three formats, one interplay

The Architecture and Reference Framework (ARF), now at version 2.x, sets the technical standards. Three of them are central for relying parties.

SD-JWT VC (Selective Disclosure JWT Verifiable Credential) is a credential format that enables selective disclosure. The issuer signs a bundle of attributes, but in a way that lets the user reveal individual ones without exposing the rest. Technically this works through salted hashes: each attribute is hashed individually, and the signature covers the hashes. Whoever discloses an attribute supplies the matching plaintext and salt, the rest stays hidden, and the signature remains verifiable.

ISO/IEC 18013-5 (mdoc) is the format originating from the mobile driving licence, used in parallel for certain attestations in the EUDI context. A relying party should be able to process both formats, since member states do not all proceed identically.

OpenID for Verifiable Presentations (OpenID4VP) is the protocol that carries the presentation. It defines how a relying party makes a request (which attributes, for what purpose) and how the wallet returns the signed response.

What selective disclosure changes in practice

The common example is age verification. Instead of transmitting the full date of birth, the wallet can disclose the derived attribute “over 18” alone. For the relying party this means formulating requests so that they receive exactly the predicate they need, not the full data set behind it. Data minimisation here is not an afterthought bolted on for privacy, but built into the protocol.

The hard part: trust, not validity

Checking a signature is the easy task. The hard one is the question behind it: is the issuer who signed this attribute actually authorised and genuine? This is where trust lists come in. The EU and the member states maintain registries through which a relying party can reliably establish whether a wallet and its issuers are authentic and authorised. Without this connection you verify a correct signature, but you do not know whether the identity behind it is trustworthy.

The reverse direction matters just as much: the relying party itself must register with a national registrar before first use, declaring which attributes it requests and for what purpose. Only this registration is the legal basis for being allowed to request data at all.

Why betting on standards pays off

Choosing open formats and protocols over proprietary adapters keeps the wallets of different member states within reach, without integrating anew per country. In our Datargo ID module this relying-party role is the through-line, from single sign-on to the EUDI path. The technical core, though, holds independently of any tool: whoever can process SD-JWT VC, mdoc and OpenID4VP and connects the trust lists correctly is ready for verification, no matter which member state the wallet comes from.

Provisioning the wallet is a political deadline. Setting verification up cleanly is a technical task, and it starts with understanding these three building blocks.