Accepting an EUDI Wallet presentation is a trust decision, and your integration code is where that decision gets made. This article is for relying parties: the municipalities and service providers that will accept wallet presentations, not the teams building wallets. It lists the questions we would want answered before the wallet is switched on for real users, as a review checklist rather than a finished design.
Know which specification you are building against
The technical foundation is the Architecture and Reference Framework (ARF). It is published in a public GitHub repository and developed under the Common Union Toolbox. The repository states that the latest authoritative version is the most recent tagged release. A branch or a blog summary is not authoritative.
The legal basis is Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, together with its Commission Implementing Regulations. The ARF points to the maintained list of those in its Introduction and References sections.
So the first questions are administrative, but they matter:
- Which ARF release did your supplier or integrator build against?
- Who on your side tracks new tagged releases and implementing regulations, and how do changes reach your backlog?
- Does your contract with the identity vendor name a version, or just "eIDAS 2.0 compliant"?
Questions about the assertion
The wallet hands your service a presentation. Before it can become a session, you need to know what you verified.
- Who issued it? Your service should accept presentations only from issuers you have decided to trust, for the attribute types you have decided to accept. "Any valid signature" is not a policy. Write the acceptance list down, name an owner, and define how entries are added and removed.
- Is it bound to this transaction? A presentation that can be replayed against your login endpoint is a stolen credential waiting to happen. Confirm with your vendor how a presentation is tied to your session, and test that an old one is rejected.
- What happens when verification fails or is unavailable? Decide whether you fail closed. Check that error handling and load conditions do not route users into a weaker fallback path.
- What do you log? You need enough to investigate an incident without storing the personal data the wallet was designed to keep minimal.
A note on the first point: the issuer and attribute acceptance policy is the control we recommend. It is not a requirement quoted from the ARF.
Questions about attributes
The Commission describes the wallet as letting users disclose only necessary details, such as age or nationality, while withholding other personal data. That sets the expectation your integration has to meet as a relying party.
If your service needs to know that someone is over a certain age, ask for that, not a date of birth. If you need a resident of your municipality, ask for the attribute that proves it, not a full address. Every extra attribute you request increases the data you must protect and justify in your own privacy assessment.
Then ask what the attribute actually proves. An attribute from a government issuer and one from a private issuer may sit in the same wallet and look alike in your code. Map each to the decision it supports. A library card number should not grant access to tax filing.
A single row of the acceptance policy might look like this. The values are an illustration of the format, not a recommendation:
| Issuer | Attribute | Relying-party decision | Owner | Review interval |
|---|---|---|---|---|
| National ID issuer (example) | Age over 18 | Allow access to the age-restricted service; do not store a date of birth | Service owner | Every six months |
If you cannot fill in all five columns for an entry, it is not ready to go on the list.
For organisational use, the pilots are testing organisational digital identities as a use case: proving that someone is a legitimate representative of an organisation. If you serve businesses, decide now how you will treat a person acting for a company, and how you will learn when that person's authority ends.
Questions about signing flows
Signing contracts is one of the pilot scenarios, so treat it as a separate assurance case from login.
- Which services does your signing or sealing flow depend on, and who operates them?
- What do you store as evidence of a signature, and for how long?
- If a signature is challenged in two years, can you show what was presented and verified at the time?
Do not assume that a successful login implies a valid signature chain. They are separate checks with separate failure modes. Your legal and security teams should agree on what counts as acceptable evidence before the first contract is signed.
Test the integration, then test it again
The Commission's prototype wallet includes code libraries and a sample application, and the reference implementation is open source. The ARF repository links to a conformance website. Use these for testing, not as a production dependency you have never reviewed.
The large-scale pilots involve over 350 entities from 26 Member States, Norway, Iceland and Ukraine, and cover areas such as government services, banking and payments. Your own endpoints, fallback paths and session handling still need their own testing.
Treat the integration as new authentication code. That means a threat model, abuse-case testing against replay, malformed presentations and unexpected issuers, and a penetration test of the finished flow before launch. Whatever the wallet vendor has tested, your relying-party service needs its own review.
Where to start
- Pin your target: record the ARF release and the implementing regulations your integration is built against, and assign someone to watch for changes.
- Write an acceptance policy: list the issuers and attribute types you will trust, the decision each one supports, the owner and the review interval.
- Cut your attribute requests down to the minimum each service needs, and record the result in your own privacy assessment.
- Build a test plan on the reference implementation and conformance resources, including replay, wrong-issuer, failure-mode and fallback-path cases.
- Separate login from signing: decide what evidence you keep for each, and who signs off on it.
- Get an independent review before go-live. If you want help scoping one, talk to our consulting team.
