What does the EU digital wallet change for a publisher?
For a publisher's web system, the European digital wallet changes one thing: instead of asking a user to upload a document and then storing it, the system requests a specific proof and receives it already verified from the user's wallet. Age verification returns a threshold rather than a date of birth, so the portal learns that the user is over eighteen without learning when they were born. Wallets are issued by member states, not by platforms, and registration of the party that verifies credentials goes through the competent national authorities.
Most coverage of European digital identity is written for governments. This is written for the person who has to decide whether it changes anything about a publishing system that currently works.
What does a publisher's system actually receive?
A proof, not a document. The current pattern for anything that needs verification is familiar and bad: the user uploads a scan, someone looks at it, the file sits in storage, and the publisher now holds a copy of an identity document it did not want and has to protect.
The wallet pattern inverts it. The system asks for one specific attribute. The wallet answers, and the answer arrives already verified. The document never moves.
Why does age verification return a threshold?
Because the portal does not need a date of birth. It needs to know whether the user is above a limit. Returning the threshold rather than the underlying date is the difference between a system that holds an answer and a system that holds personal data it now has to defend.
This is the part most worth understanding, because it changes what a publisher is liable for rather than only how a form looks.
What can be built with it today?
- Sign-in with a wallet
- Early access
- Age verification
- Early access
- Attribute verification
- Early access
- Document signing
- Later phase
Early access means the path from request to record is built and monitored, not that the ecosystem around it is finished. A publisher planning a launch date around it is planning around someone else's timetable.
Who issues the wallet, and who verifies?
Wallets are issued by member states. No platform issues one, and any supplier claiming otherwise is describing something else. The party on the other side, the one that requests and verifies a credential, registers through the competent national authorities. That registration is the publisher's or the integrator's to obtain; it is not something an integration layer can grant.
Being explicit about this matters, because the gap between what an integration covers and what a regulator has to approve is exactly where a project stalls.
How large is the integration?
Seven steps, from the request for a proof to the record of it, rather than a six-month programme. The integration is monitored like anything else in production: a check every five minutes on whether the path still resolves, whether the schema is still valid, and whether the trust chain is complete.
That last point is not decoration. An identity integration that silently stops verifying is worse than one that was never built, because the system keeps admitting users while believing it checked them.
Should a publisher do anything now?
One thing, and it costs nothing: write down which parts of the portal currently ask a user to prove something, and what is stored as a result. Most publishers find at least one place where a document is being kept because there was no other way to answer a yes-or-no question. Those are the places where this changes the work.