This page summarises the protocols, standards, credential formats, and implementation profiles used in the EU Digital Identity ecosystem. It serves as a compact reference; detailed user journeys and flow diagrams are in the User Journey.
ISO/IEC 18013-7 defines how mobile driving licences (mDLs) and generic mDocs are presented over the internet (remote presentation), extending the proximity-based protocols of ISO/IEC 18013-5. Three distinct annexes define different transport and invocation mechanisms.
Annex C defines two sub-protocols that both run over the W3C Digital Credentials API
(navigator.credentials.get({ digital: ... })). The browser/OS handles wallet discovery,
invocation, and user consent via a credential chooser, then delivers the request to the
user-selected wallet.
This is what wallets actually implement. The verifier sends a standard OpenID4VP Authorization
Request (with dcql_query, nonce, client_metadata), and the wallet returns a VP Token
— all tunnelled through the DC API instead of via openid4vp:// deep links or direct_post.
Aspect
Detail
Protocol identifiers
openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned (see OpenID4VP §A.1)
Standard OpenID4VP Authorization Request parameters as JSON in the data field: response_type, response_mode, nonce, dcql_query, client_metadata, optionally client_id and request for signed requests
Response payload
OpenID4VP Authorization Response containing the vp_token, optionally JWE-encrypted (response_mode: "dc_api.jwt"): the encrypted JWT is returned as a JSON string in the data field
Response modes
dc_api (unencrypted JSON, not recommended) or dc_api.jwt (JWE-encrypted Authorization Response — the wallet encrypts the vp_token using the verifier’s public key from client_metadata.jwks, per OpenID4VP §8.3)
Wallet support
Theoretical — not yet confirmed in production. The EUDI Wallet Core library includes DC API handling code, but production wallets (France Identité, EUDI Wallet DE, IT Wallet, Spanish EUDIW) do not yet recognize the openid4vp protocol identifier inside the DC API handler. See the demo webapp page for details.
Not yet demonstrated in production — documented as broken on Android 15+ in practice (see the demo webapp page)
In short: “Wraps OpenID4VP as dc_api.jwt” means the wallet receives a standard OpenID4VP
Authorization Request through the DC API, processes it with its existing OpenID4VP handler,
then encrypts the resulting VP Token as a JWE (using response_mode: dc_api.jwt) before
returning it through the DC API.
OpenID4VP Annex B (redirect_uri scheme, no JAR, direct_post)
Request signing
No JAR — deliberately omitted to prevent verifier tracking
Privacy model
Double-blind: verifier gets binary yes/no without user identity; issuer cannot see where credential is used
Client ID scheme
redirect_uri (fallback only)
Credential format
mso_mdoc (eu.europa.ec.av.1)
Wallet support
AV-compatible wallets (EUDI Wallet Referenz, AVI) via Annex B deep-link fallback. Annex C (W3C DC API) is the specified primary method, but no wallet has demonstrated working Annex C support in production as of mid-2026.
Wallet support for ISO/IEC 18013-7 annexes across major European member states, based on observed behaviour in testing and public documentation (as of May 2026):
Scheme
Transport
Payload
Trust
France
Germany
Italy
Spain
ISO 18013-7 Annex A
HTTP REST API
CBOR DeviceRequest/Response
Network-layer encryption
❌ Not implemented
❌ Not implemented
❌ Not implemented
❌ Not implemented
ISO 18013-7 Annex B
openid4vp://, direct_post
DCQL (JSON)
JAR + TLS
✅ Production, DCQL + JAR
✅ Beta/Sandbox, DCQL + JAR
✅ Production, DCQL + JAR
✅ Pilot, DCQL + JAR
ISO 18013-7 Annex C
navigator.credentials.get()
Sub-protocol A: CBOR ["dcapi",...] + HPKE
Sub-protocol B: OpenID4VP JSON + JWE (dc_api.jwt)
Web origins + App Links
⚠️ Sub-protocol B: in development — EUDI Wallet Core added DC API support, but the openid4vp protocol identifier is not yet recognised by production wallets (see note below)
❌ Sub-protocol A: not implemented
⚠️ Sub-protocol B: in development (same limitation)
❌ Sub-protocol A: not implemented
⚠️ Sub-protocol B: in development (same limitation)
❌ Sub-protocol A: not implemented
⚠️ Sub-protocol B: in development (same limitation)
❌ Sub-protocol A: not implemented
Note on Annex C: While the EUDI Wallet Core library includes DC API plumbing, production wallets reject the openid4vp protocol identifier with “Unsupported protocol” errors. The W3C DC API Annex C flow is therefore not functional with any current EUDI wallet. All wallets use Annex B (deep-link OpenID4VP) for production flows. See the demo webapp page for the full technical analysis.
| OpenID4VP HAIP | OpenID4VP, direct_post.jwt | DCQL | Strict JAR + EU Trust List | ✅ DCQL + strict JAR | ✅ DCQL + strict JAR | ✅ DCQL + strict JAR | ✅ DCQL + strict JAR |
| EUDIW EU-AV Blueprint | Priority: Annex C → Annex B | DCQL (minimal disclosure) | No JAR | ✅ Drops JAR for privacy | ✅ Drops JAR for privacy | ✅ Drops JAR for privacy | ✅ Core focus, drops JAR |
Note: This matrix reflects observed wallet behaviour from testing and public documentation, not formal compliance certifications. Wallet capabilities evolve rapidly — consult each member state’s latest wallet release notes for current status.