The European Digital Identity Wallet is on its way, and with it the obligation for many service providers to accept it. More interesting than the obligation is what it makes possible: asking only for what you actually need. We build that integration alongside your existing login methods, not in place of them.
With the revision of eIDAS (Regulation (EU) 2024/1183), every Member State is required to offer citizens and businesses a digital identity wallet. The European timeline is for these wallets to be available by the end of 2026; the Netherlands is working on its own public wallet. For service providers, an acceptance obligation follows, with its own timeline that depends on the implementing acts. An important detail: the obligation concerns recognised wallets in general, so waiting for one specific wallet is not a strategy.
What makes this interesting beyond the obligation is the data minimisation side. Many organisations ask for more than they need when someone logs in or submits an application, simply because the tool gave them no other option. With selective disclosure, you can request derived attributes instead of the underlying data: not the date of birth but whether someone is over eighteen, not the full address but the municipality. Fewer questions mean less storage and less explaining.
We build the relying party side: the request you send to the wallet, checking what comes back, and linking it to the identity you already hold in your system. This almost always touches your existing login chain and sometimes your integrations with other systems. For organisations also working on information security, we set it up so the two projects do not get in each other's way.
We build this as a standalone piece and as part of custom software development. If you currently use DigiD or eHerkenning, the wallet route is added alongside them. How we handle identity data is set out in our information security policy.
Where you start depends on what you use identity for: logging in, checking a single attribute, or building a file. We'll determine that in the first conversation.
A second route to the same identity in your system. For your users, nothing changes at first: a button is added. Technically, the design work is mainly about linking: someone who logs in today with an existing method and tomorrow with a wallet should be the same person and see the same record. We build that route so it can be switched off separately, so that changes to the standards do not affect your existing services.
Age limit, place of residence, professional licence, signing authority. Instead of asking for and storing a document, you request confirmation and keep only the answer. That saves you retention periods, explanation and risk. To do this, we first review your forms: which data you request, why, and which derived attribute you actually need. In practice, that clean-up often delivers more than the wallet itself.
Alongside identity, wallets can carry statements issued by an organisation: a diploma, a membership, a licence, a customer status. If you are the party issuing such credentials, we build the issuance side; if you are the party verifying them, we build the verification side. Often both, because organisations that issue credentials usually also want to be able to check what others have issued.
A working integration alongside your existing login methods, with the documentation you need to register as a relying party.
Four situations in which it makes sense to look at this now rather than wait until the deadline is in sight.
For public service providers and for services that must use strong authentication by law, the obligation to accept recognised wallets is coming. Those who make their identity layer extensible now will not have to do it under time pressure later.
There are fields on your form that nobody knows the reason for any more, and you store documents when you only needed a confirmation from them. That is a risk now and will be unnecessary once selective disclosure is in place.
Extracts, identity documents or diplomas are uploaded and checked by hand. That is slow, error-prone, and leaves you with a retention obligation for data you would rather not have had.
When knowledge about authentication is spread throughout your entire application, every new login method becomes a rebuild. Tidying that up now has value already and turns the wallet into an addition rather than a project.
What do you use identity for: logging in, checking an attribute, or building a file? Which login methods are running today, and how are they embedded in your application? That last question often determines half the work, because a scattered authentication chain costs more than the wallet itself.
A working session in which we determine, per form and per field: why do you ask this, is it necessary or desirable, and which derived value is sufficient? Necessary and desirable should behave differently in your software, and that distinction is almost always missing.
We work in sprints. First we make the identity layer such that a method can be added without you having to change anything everywhere, then the wallet route itself, then the attributes. Your own developers take part, because this touches the core of your application.
The standards exist and there are test setups to test against, well before the public wallets are widely available. We also test the path in which someone has no wallet or refuses an attribute, because that is the path most often skipped in practice.
The documentation for your registration as an accepting party, a handover to your team, and agreements about what happens if the standards or the national implementation change. In this file, that last point is not a theoretical scenario.
What product owners, architects and privacy officers ask us before they start on this.
A thirty-minute introductory call, no obligation. Tell us which data you currently request and how your login is arranged, and we'll say what should come first and what can wait, even if we ultimately don't work together.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
