EUDI Wallet Integration
The first decision in an EUDI Wallet integration is not which vendor to buy. It is which credential format you accept, because one route keeps the whole build inside specifications the framework itself sets requirements out from and the other puts an ISO standard your team has to obtain separately on the critical path.
11 min read
70 views
- Annex 2 names the work, not the prose chapter The framework's high-level requirements name the HAIP sections a relying party has to implement, by number. Two of them cover a remote SD-JWT VC verifier, and the transport chosen decides which one applies.
- The remote route forks once more, into two transports The framework names two transmission mechanisms for carrying presentation requests and responses, redirects with a custom URI scheme and the W3C Digital Credentials API. The pick is a platform decision and it moves one line of the conformance list.
- One of the two differences is punctuation OIA_03c and OIA_08a differ in HAIP Section 5.1 versus 5.2, and also in a comma before the final and. A naive diff reports two changes when only one carries meaning.
- The wallet carries the consent step For transactional data the wallet processes the values, consults the user and signs a representation of them. The verifier's side of that work is putting the right values into the request and checking what returns.
- Requirement identifiers are version-bound The identifiers and section numbers here are from version 3.0.0 of the framework. Confirm the version in front of you and re-check both Annex 2 requirements against it before freezing a conformance checklist.
An EU business that wants to accept EUDI Wallet credentials usually starts by asking which vendor to buy. That is the second question. The first one is a format decision, and it is the one that moves the budget: the credential format you agree to accept determines which specifications your engineers have to obtain, read and conform to. One of the two routes puts an ISO standard your team has to obtain separately on the critical path before anyone writes code.
Everything below is sourced to the European Commission's Architecture and Reference Framework, version 3.0.0, which names the protocols the ecosystem uses and the profiles a relying party has to conform to. Where a protocol detail appears, it is the framework's characterization of that protocol rather than a reading of the underlying specification, because it is the framework that binds a relying party.
The scoping decision that sets your budget
Two presentation routes exist and they do not overlap. In the remote route the user is on your web or mobile channel, the wallet is reached over the network and the credential is an SD-JWT VC. In the proximity route the user is standing in front of a device, the credential is an mdoc and the wire protocol comes from ISO.
The framework is unambiguous about the second route. "Within the EUDI Wallet ecosystem, the protocol and transmission mechanism specified in ISO/IEC 18013-5 is used for proximity attestation presentation flows." (ARF v3.0.0, chapter 5)
It is equally short about the first. Of the remote protocol the framework states that "OpenID4VP is suitable only for remote presentation transaction flows." (ARF v3.0.0, chapter 5) Protocol choice and presentation mode are therefore not two decisions a team can sequence. They are one.
Why one format choice removes two ISO dependencies
The framework closes the route from both ends, and this is where both ISO dependencies actually get removed. It states that attestations compliant with SD-JWT VC cannot be used in proximity presentations. It also states that ISO/IEC 18013-7, the remote member of the ISO family, can only be used to request and present attestations in the ISO/IEC 18013-5 format. (ARF v3.0.0, chapter 5)
So a single decision removes two dependencies at once. A verifier that accepts SD-JWT VC credentials over a remote channel never needs ISO/IEC 18013-5 for presentation, and never needs ISO/IEC 18013-7 either. What that is worth turns on how the framework handles the ISO route, and the framework's own statement on proximity, quoted above, shows the shape of it: it points at ISO/IEC 18013-5 rather than setting that standard's requirements out in its own text. Any reader can check that structure directly in the cited chapter. The practical consequence is that a team on the mdoc or proximity route works from a document held outside the framework and has to obtain it separately, while the remote SD-JWT VC route conforms to requirements written out in the framework and its annexes, in the passages quoted further down this page.
| Scoping line | Remote route | Proximity route |
|---|---|---|
| Credential format | SD-JWT VC | mdoc |
| Presentation protocol | OpenID4VP, profiled by HAIP | ISO/IEC 18013-5, or ISO/IEC 18013-7 for remote mdoc |
| Issuance protocol | OpenID4VCI, profiled by HAIP | OpenID4VCI, profiled by HAIP |
| Specifications to obtain | Documents the ARF sets requirements out from | ISO/IEC 18013-5, which the ARF points to |
| Typical trigger | Web or app onboarding, remote authorization | Counter, gate or device-to-device check |
Compliance scope rather than the feature list sets the number in wider regulated builds too: what compliance adds to a FinTech MVP budget.
Two transports, and only two
Inside the remote route there is a smaller fork, and it changes exactly one line of your conformance checklist. The framework says that "HAIP specifies two transmission mechanisms for transporting presentation requests and responses between a Relying Party Instance and a Wallet Unit." (ARF v3.0.0, chapter 5)
Most web integrations will reach for the first of them: "The first uses redirects and is based on the use of a custom URI scheme." (ARF v3.0.0, chapter 5) The second is the W3C Digital Credentials API, which the framework names by reference in the sentence immediately after. Picking between them is a platform question more than a compliance question, but it is not a decision you can defer, because the framework's requirements name different profile sections for each.
HAIP is three profiles, not one
HAIP is not one obligation. The framework applies it separately at three layers, giving the same reason each time: the underlying specification carries too many options for interoperability to survive without a profile.
At the presentation protocol layer the framework states that "Since OpenID4VP contains a number of options, the use of the profile for 'OpenID for Verifiable Presentations for IETF SD-JWT VC' specified in HAIP is necessary to ensure interoperability between Wallet Units and Relying Parties." (ARF v3.0.0, chapter 5)
The same construction appears earlier in the chapter, about the credential format rather than the protocol: "Since SD-JWT VC contains a number of options, the use of the profile for SD-JWT VCs specified in HAIP is necessary to ensure interoperability between Wallet Units and Relying Parties." (ARF v3.0.0, chapter 5) A team that scoped HAIP once, against OpenID4VP, has already missed this one.
Issuance is a separate scope line
If you only verify credentials that somebody else issued, you can stop at two profiles. If you also issue attestations into user wallets, an account credential or a membership of your own, then a third protocol and a third profile enter the scope. On issuance the framework leaves no alternative: "Within the EUDI Wallet ecosystem, the protocol and transmission mechanism specified in OpenID4VCI is used for PID and attestation issuance flows." (ARF v3.0.0, chapter 5)
And the profile obligation repeats a third time: "Since OpenID4VCI contains a number of options, the use of the profile for 'OpenID for Verifiable Credential Issuance' specified in HAIP is necessary to ensure interoperability between Wallet Units and Relying Parties." (ARF v3.0.0, chapter 5) Verification and issuance are two projects, and only the first is required to accept somebody else's credential. Which PID fields an issuance flow actually returns, and what a guaranteed field is worth: PID attributes at onboarding.
The requirement that names the work
The most useful part of the framework for a verifier team is not the prose chapter. It is Annex 2, where the high-level requirements name the HAIP sections a relying party has to implement, by number. Two requirements cover the remote SD-JWT VC verifier, and which one applies depends only on the transport chosen above.
For remote presentation using redirects and OpenID4VP, where the requested attestation is in SD-JWT VC format, requirement OIA_03c states that "Relying Parties and Wallet Units SHALL comply with the requirements in HAIP Sections 5, 5.1, and 5.3.2, as well as with the 'IETF SD-JWT VCs' profile in Section 6 and with Sections 7 and 8" and lists nothing else. (ARF v3.0.0, Annex 2)
The same build, one section different
Swap the transport and the obligation shifts by one section number. Requirement OIA_08a, which covers the same credential format over the W3C Digital Credentials API, states that "Relying Parties and Wallet Units SHALL comply with the requirements in HAIP Sections 5, 5.2 and 5.3.2, as well as with the 'IETF SD-JWT VCs' profile in Section 6 and with Sections 7 and 8." (ARF v3.0.0, Annex 2)
Section 5.1 governs the redirect transport and 5.2 governs the Digital Credentials API transport. Everything else in the two lists is identical. There is a second difference between the two strings and it is cosmetic: one requirement puts a comma before the final and in its list of sections, the other does not. That is punctuation drift in the source document rather than a semantic distinction, so a naive diff of the two requirements reports two changes when only one of them is real.
| Requirement | Transport it covers | HAIP sections named |
|---|---|---|
| OIA_03c | Redirects with a custom URI scheme | 5, 5.1, 5.3.2, 6, 7, 8 |
| OIA_08a | W3C Digital Credentials API | 5, 5.2, 5.3.2, 6, 7, 8 |
What the SD-JWT VC profile pulls in on top
Both requirements carry a note, and the note is where under-scoping usually happens. Read the requirement alone and you get a list of HAIP sections. The note adds material from a second document: "the 'IETF SD-JWT VCs' profile implies that Relying Parties and Wallet Units must comply with the requirements in OpenID4VP Annex B.3, as well as with the requirements in Section 6.1." (ARF v3.0.0, Annex 2)
Your conformance list is therefore longer than the requirement sentence suggests. Annex B.3 of OpenID4VP and Section 6.1 of HAIP are in scope because the SD-JWT VC profile brings them in, even though neither appears in the numbered list you started from. Budget the reading time for both before the estimate is signed off, not after.
A second note closes a reading error.
Where the requirements say HAIP Section 5, they mean the requirements written directly under that heading and not the subsections beneath it: "This does not include sections 5.1, 5.2, and 5.3." (ARF v3.0.0, Annex 2) Reading Section 5 as everything beneath it pulls in material the requirement does not name. The list is exact, which is why 5.1 and 5.3.2 appear in it separately.
Transactional data comes with the presentation, not on top of it
A verifier may need the user to approve something specific, an amount or a counterparty. That does not require a protocol extension. The framework states that "Both ISO/IEC 18013-5 and OpenID4VP allow for sending, authenticating, and returning transactional data. In both protocols, the presentation request can be extended with use-case specific (proprietary) transactional data." (ARF v3.0.0, chapter 5)
The framework's own worked example is a payment: "In the case of strong customer authentication for payments, the Relying Party sends payment information, such as the payment amount and the payee, to the Wallet Unit." (ARF v3.0.0, chapter 5)
What comes back has been signed by the wallet after the user has seen it: "The Wallet Unit will process the transactional data in a use-case specific way, and, after consulting the User, will sign a (representation of the) transactional data to authenticate it." (ARF v3.0.0, chapter 5) For a verifier team that is a saving. The consent screen and the signature over the transaction detail sit on the wallet side. Your side of the work is putting the right values into the request and checking what returns. How a payment service processes a wallet-presented SCA attestation: strong customer authentication with the EUDI Wallet.
The same shape appears in payments, where a check has to clear before money moves: verification of payee implementation.
A build order that follows from the requirements
- Settle format and presentation mode as one decision. Remote plus SD-JWT VC, or proximity plus mdoc. Whether a standard has to be obtained from ISO follows from this line.
- Pick the transport. Redirects with a custom URI scheme, or the W3C Digital Credentials API. The choice selects which of the two Annex 2 requirements applies.
- Turn that requirement into a checklist. Take the HAIP sections it names, add OpenID4VP Annex B.3 and HAIP Section 6.1 from the note, and read HAIP Section 5 as the requirements directly under that heading only.
- Scope the protocol work from what the framework says the standard covers: "The OpenID4VP standard defines message structures, transaction flows, and an HTTP-based interface specification for attestation presentations by Wallet Units to Relying Parties." (ARF v3.0.0, chapter 5) Three deliverables to size.
- Decide on issuance. Verifying only, stop here. Issuing as well, add OpenID4VCI and its HAIP profile as a separate workstream with its own conformance list.
- Add transactional data only where the transaction needs the user's signature, treated as field mapping and not a protocol change.
- Budget interoperability testing as its own line. Each profile exists because the underlying specification carries too many options for interoperability to survive without one, so profile conformance is what that testing establishes.
One prerequisite sits outside this list. Becoming authorised and registered as a relying party is a separate step from building the verifier, and this page does not cover it. What that step requires: relying party registration.
What the decision looks like on a budget line
The two routes produce differently shaped scopes. A remote SD-JWT VC verifier resolves to one Annex 2 requirement plus its notes, so the conformance list is finite and can be written out before the estimate is. A proximity or mdoc verifier adds a standard that has to be obtained from ISO first, which puts an acquisition step ahead of the estimate rather than inside it, and deferring that step does not remove it.
The remote route serves the case where a user is on a website or in an app, proving an attribute so an account can open or a transaction can proceed. Where that is the build in front of you, the SD-JWT VC and OpenID4VP route covers it and the ISO family never enters the scope. On where an attribute check belongs in a regulated onboarding flow: KYC obligations under MiCA.
One caution on versions. The framework moves, and the requirement identifiers and section numbers quoted here are from version 3.0.0. Before you freeze a conformance checklist, confirm the version you are reading and re-check the two Annex 2 requirements against it, because an implementation plan built on a superseded section list is worse than one that never named a version.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 5
No matches
Try a different keyword, change the topic or clear filters
-
The remote route, where the credential is an SD-JWT VC and presentation runs over OpenID4VP profiled by HAIP. The Architecture and Reference Framework assigns proximity presentation to ISO/IEC 18013-5, and the remote ISO profile, 18013-7, can only carry attestations in the ISO/IEC 18013-5 format.
A single format decision therefore removes both ISO dependencies from the build.
-
Both cover a remote verifier accepting the SD-JWT VC format, over different transports. OIA_03c names HAIP Section 5.1, which governs redirects with a custom URI scheme.
OIA_08a names Section 5.2, which governs the W3C Digital Credentials API. Every other section named in the two requirements is the same.
-
No. A note attached to both requirements adds OpenID4VP Annex B.3 and HAIP Section 6.1, pulled in by the SD-JWT VC profile. The same note also narrows what HAIP Section 5 means, to the requirements written directly under that heading rather than its subsections.
-
No extension is needed. The framework states that both ISO/IEC 18013-5 and OpenID4VP allow transactional data to be sent, authenticated and returned.
It adds that a presentation request can be extended with use case specific data. Strong customer authentication for payments is the framework's own worked example, with the relying party sending the amount and the payee.
-
No. OpenID4VCI is the issuance protocol, and the framework requires it for PID and attestation issuance flows. A relying party that only accepts credentials somebody else issued implements two HAIP profiles, one for the SD-JWT VC format and one for OpenID4VP.
Issuing attestations of your own adds OpenID4VCI and a third profile as a separate workstream.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
