OpenID4VP 1.0: what the standard change means for organisations connecting to DÁP
A decision guide for business and IT leaders
The OpenID4VP standard has reached its final 1.0 version, which means every organisation that built its DÁP e-identification connection on draft 22 — or that is integrating right now — is facing a migration task. This article does not cover the technical details, but what a business or IT leader needs to know: how big this task really is, why it will not be the last change of its kind, and how to decide between custom development and an off-the-shelf solution.
Table of Contents
1. What happened, and why is action mandatory?
EU Implementing Regulation 2024/2977 and the EUDI Wallet framework mandate uniform, cross-border interoperability between member states. This requires every participant to follow the final standards: the Hungarian solution must comply with the OpenID4VP 1.0 specification and the related EU profiles. Draft 22 — like every draft-status specification — was a transitional state: it cannot be maintained in a production service operated over the long term.
Draft 22
The previous integration baseline
OpenID4VP 1.0
The final standard + the EU profiles
A 1.0-capable solution
Also the right choice for integrations still under development
Hard switch
When 1.0 goes live, the service provider automatically moves to the new standard.
Continuous tracking
Handling future changes
The practical consequence: a single-step cutover (a “hard switch”) is expected on the DÁP side. This means that from a given date the system will only accept messages compliant with the 1.0 standard. Any organisation that is not ready by then will see its e-identification integration stop working on that day. The exact dates are not final yet — but given the size of the preparation work, that is precisely the best argument for not waiting until the date is announced before starting to plan.
Key message: On the day of the hard switch, integrations that have not been updated may stop working. Preparation therefore cannot be postponed until the final date is announced.
2. Why is this not a two-day task?
The two versions are not backward compatible in several respects. This is not a version-number change, but a transformation affecting multiple layers of the integration. A few examples, translated into business terms:
- 1
The query language is replaced
The previous Presentation Exchange format is replaced by DCQL. The construction of requests, the processing of responses and the related business logic all have to be rewritten and retested.
- 2
The digital identification of the organisation changes
Verifier identification moves to a new, certificate-hash based scheme (x509_hash). This affects both how requests are assembled and how responses are validated.
- 3
The response structure and error handling change
The previous mapping mechanism is discontinued, and around 25 new error codes are introduced. These have to be handled in logging and in business processes as well.
- 4
A migration strategy has to be chosen
Either one application supports both versions in parallel, or two separate implementations run and traffic is switched over on the cutover day.
All of this requires development, comprehensive retesting and compliance verification — while the old version has to keep running flawlessly until the day of the hard switch. Neither migration strategy is trivial, and both require substantial planning, development capacity and operational readiness.
The total effort — depending on the maturity of the existing implementation — is realistically measured in months.
3. This is not expected to be the last change
The EUDI ecosystem is evolving at EU level, and the current migration documentation already names the next changes: the current revocation-checking mechanism may be replaced by the IETF Token Status List, and a new format is being introduced for trusted lists.
“In other words, an organisation migrating to 1.0 today has not closed the topic — it has entered a continuously maintained standards environment that keeps moving at European level.”
This realisation is the key to the strategic decision.
Prepare for the migration in good time
Let us look together at what the OpenID4VP 1.0 migration means for your integration, and how standards tracking can become a predictable, plannable cost.
EUDI Wallet integration packages4. Custom development or an off-the-shelf solution?
At many organisations the reaction is understandable: “the integration is already running or finished, we do not want to reopen the project.” The question, however, is not whether it has to be reopened — the standard change means it has to be touched in any case. The real question is who should carry the maintenance burden over the coming years.
Organisations that built on draft 22 have to prepare for the 1.0 hard switch. Those whose integration is still in progress should already be choosing a solution that will also handle OpenID4VP 1.0.
Custom development
- The burden of tracking the standards stays with the organisation
- Key-person dependency and competence risk
- The migration shows up as a development project
- The risk of downtime depends on your own readiness
- Higher TCO measured over several years
Off-the-shelf solution
- Standards tracking is part of the product
- The migration can be handled as a version upgrade
- Development and testing are the vendor's responsibility
- Contractual accountability and more predictable operation
- More predictable operation and lower TCO
5. The most important aspects of the return on investment
The decision is best made on a multi-year TCO basis, not solely on the one-off cost of the current migration.
| Cost item | Custom development | Off-the-shelf solution |
|---|---|---|
| Current draft 22 → 1.0 migration | Development + testing + compliance in-house | Version update from the vendor |
| Next changes already announced | The same development and testing cycle again | Delivered as part of the product |
| Continuous standards tracking | Dedicated expert capacity every year | Included in the service fee |
| Competency risk | At the organisation, with key-person dependency | At the vendor |
| Risk of downtime on the hard switch day | Depends on your own readiness | Contractual responsibility |
The decision logic is simple: the price of custom development is not the current project, but the current project multiplied by the number of future standard changes, plus the cost of continuous readiness. In a narrow, fast-moving field this typically only pays off if digital identity is the organisation's core activity.
6. Questions worth asking now
Whether the integration was built in-house or delivered by an external developer, the following questions quickly reveal where the organisation stands:
- Who tracks changes to OpenID4VP and the EUDI framework in our organisation?
- Do we have an estimate for the effort of the draft 22 → 1.0 migration, and is it in the development roadmap?
- Which migration strategy are we choosing, and have we tested the cutover?
- What happens to our identification processes if we are not ready on the day of the hard switch?
- Under the current arrangement, who bears the cost and responsibility of the next standard change?
7. Prepare for the migration in good time
TrustID Solutions offers a ready-made, continuously maintained solution for DÁP e-identification and HAASZ data service integrations, in which standards tracking — including the current OpenID4VP 1.0 migration — is part of the product.
Technical details for developers
OpenID4VP & EUDI Wallet: What changes for Relying Parties — a detailed developer guide covering DCQL, verifier identification, response packaging and trust infrastructure.
View the technical guideWe can help you assess the migration
If you would like to assess what the migration means for your integration, get in touch with us.
Contact usRelated Articles
OpenID4VP & EUDI Wallet: What changes for Relying Parties (Verifier / RP)
Technical details for developers on the standard changes: DCQL, verifier identification, response packaging and trust infrastructure.
EUDI Wallet Integration Guide
Step-by-step technical guide to integrating with the DÁP e-identification service.
EUDI Wallet Overview
An overview of the EU Digital Identity Wallet ecosystem and its components.