Developer Guide18-22 min read

OpenID4VP & EUDI Wallet: What's Changing for Relying Parties

Developer Guide

Whether you have already started or even completed the DÁP integration, or you are just preparing for your first connection, the upcoming standard changes will definitely affect you. This article summarizes the upcoming changes and explains clearly what they mean for planning, implementing, and sustainably operating your integration project.

Overview

The European Digital Identity Framework is pushing the ecosystem toward consistent, cross-country interoperability between wallets and relying parties. In practice, this affects any verifier integration that relies on a digital identity wallet—including the EU Digital Identity Wallet app (often referenced as the EUDI Wallet / EudiWallet) and national integrations such as Digital Citizen (DÁP).

For organizations implementing DÁP e-identification and enterprise identity flows—especially for KYC process automation or digital age verification—these changes matter because they reduce ambiguity in request semantics, metadata usage, response containers, and schema/trust processing.

You can think of this as a maturation step in the wider Digital Identity Framework: fewer optional patterns, clearer negotiation, and cleaner payloads—making it easier to build and operate a reliable EU digital identity solution.

Already working on your integration?

Our EUDI Wallet Integration Guide provides a step-by-step technical walkthrough for connecting to the DÁP eIdentification service as a Relying Party.

Read the EUDI Wallet Integration Guide

2. DCQL replaces Presentation Exchange in EU-grade interoperability

Instead of using DIF Presentation Exchange presentation_definition as the primary request structure, ecosystems are introducing DCQL (Digital Credentials Query Language) as the preferred way to express verifier requirements.

Presentation Exchange has been improved based on real life feedback and usability to serve the Wallet ecosystem better. DCQL is designed to reduce ambiguity and make requests more explicit and predictable in case of complex use cases as well.

With DCQL, a verifier expresses requirements as structured queries, what credential(s) are acceptable, which claims are required, how alternatives are allowed, and how combinations satisfy policy.

3. Wallet metadata restructuring

The wallet metadata structure is evolving into a more unified and logically grouped model. This concerns how wallets publish what they support, such as credential formats, cryptographic algorithms and key types, response protection approaches, and interaction patterns.

In the EUDI Wallet ecosystem, metadata is the basis of interoperability. A more standardized metadata structure reduces wallet-specific handling and trial-and-error troubleshooting.

4. Clearer capability & algorithm negotiation

The negotiation process between wallets and relying parties for algorithms and capabilities becomes clearer—enabling more deterministic agreement on credential format compatibility, encryption and signing suites, and response protection patterns.

Most production interoperability issues come from capability mismatches. Clearer negotiation reduces failures and accelerates go-live.

5. Verifier identification changes: x509_hash client_id prefix

A new client_id prefix/scheme is introduced: x509_hash. The objective is to improve EU interoperability because x509_san_dns expectations were not consistently applicable across national deployments.

Verifier identity becomes bound to certificate material via a hash-based identifier. Using a certificate hash (x509_hash) simplifies trust handling, standardizes client IDs across implementations, and avoids optional resolution mechanisms that made interoperability harder.

Looking for a ready-made solution?

Our EUDI Wallet integration packages include SDK and turnkey solutions that handle OpenID4VP client implementation, certificate management, and cryptographic verifications out of the box.

View Integration Packages

6. SD-JWT format identifier: vc+sd-jwt → dc+sd-jwt

For SD-JWT credentials, the format identifier changes from vc+sd-jwt to dc+sd-jwt.

7. Response packaging simplification (JARM out, simpler encrypted token in)

A previously used response formatting approach is removed in favor of a simpler protected response container, commonly represented as a JWE token depending on the ecosystem's protection requirements.

Response packaging determines:

Confidentiality and integrity properties
Response correlation
Consistent implementation across stacks—especially under eIDAS 2.0 aligned security and governance expectations

8. Response mapping simplification (presentation_submission → simple map)

Instead of using a complex mapping element for correlating requested items to returned credentials, responses carry credentials via a simpler mapping approach—an explicit map keyed by identifiers.

This reduces backend processing complexity, improves traceability/logging, and speeds integration cycles for teams delivering SDK-based verifier components.

9. Schemas: EU + national extensions, inheritance, PID updates

Schema handling moves toward a unified approach for EU-level schemas and country-specific schemas, introducing inheritance mechanisms (base + extension). PID schema updates follow PID rulebook changes.

Verifiers must handle common EU credentials, national extensions without brittle country-by-country logic, and version changes that otherwise break downstream business rules. This is key for compliance tracking and long-term operability.

Want to understand the EUDI Wallet architecture?

Our EUDI Wallet overview explains the wallet ecosystem, credential formats, and how schemas and trust models fit together.

Read EUDI Wallet Overview

10. Trust infrastructure: TL (XML→JSON in some cases) and ARL/status list changes

In certain cases, an XML-based TL format is replaced or complemented by a JSON-based format. ARL format changes introduce new status and identifier lists aligned with updated ARF conventions.

Trust infrastructure is security-critical. It determines:

Which issuers/providers are trusted
Which entities are valid at a given time
How status changes affect acceptance policy

Robust ingestion, validation, caching, and monitoring are essential.

11. Additional changes many teams miss

Silent abort behavior: wallets may not provide detailed error information before explicit user consent. Production systems must treat cancel/abort outcomes as normal and instrument them properly.
Holder binding assumptions: do not assume every response is cryptographically holder-bound unless your request/profile explicitly requires it.
Operational compatibility management: maintaining a wallet/version compatibility matrix becomes essential when delivering verifier capabilities at scale.
Compliance and evidence: long-term success requires strong compliance tracking, traceability, and audit-friendly logging.

12. Summary for Relying Parties (implementation checklist)

Request construction:

Implement DCQL-based request generation and make it deterministic and metadata-driven

Verifier identity:

Support x509_hash client identification

Response processing:

Build a robust pipeline (detect → decrypt/verify → extract → validate)
Ensure SD-JWT processing supports dc+sd-jwt

Schema management:

Treat schemas as versioned dependencies (EU base + national extensions) and apply PID updates consistently

Trust infrastructure:

Implement TL/ARL ingestion with integrity checks, caching/refresh, monitoring, and auditable logs

Operational readiness:

Maintain a compatibility matrix
Track production metrics (completion rate, user-cancel rate, trust update impacts)

Need help navigating these changes?

Our team specializes in EUDI Wallet and eIDAS 2.0 integrations. We can help you plan, implement, and operate a compliant verifier solution.