What EU Digital Identity Wallets Could Mean for Drupal
European Digital Identity Wallets are moving from technical framework and pilot programmes towards services that people will be able to use across the European Union. The European Commission says Member States must make wallets available to citizens, residents, and businesses by the end of 2026. For Drupal teams, that makes digital identity less a future policy topic and more an application-architecture question.
The wallet model changes what an online service can ask a user to prove. Instead of treating identity as one complete profile, users can present particular identity data or attestations and disclose only the information required for a transaction. Commission figures say more than 550 companies and public authorities across 26 Member States, Norway, Iceland, and Ukraine are participating in large-scale pilots covering government services, banking, education, health, transport, telecommunications, and other uses.
The relevant role for a Drupal application is the relying party. Under the European framework, organisations that use wallets for digital services must register their intended use and indicate the data they plan to request. That puts the request itself inside a defined trust and registration model rather than leaving every application to decide independently what identity information it wants to collect.
The technical exchange is also more specific than adding another login provider. For remote presentation flows, the EUDI architecture uses OpenID for Verifiable Presentations to carry requests and wallet responses between wallets and relying parties. A Drupal service could potentially use a validated result from that layer for authentication, account linking, permissions, eligibility checks, or workflow decisions, but the material reviewed for this issue does not establish a production-ready Drupal integration that provides those functions today.
Data handling may prove more consequential than authentication itself. A wallet may be able to prove that a person has a particular attribute without requiring the service to collect a larger identity record, and the European framework is designed around data minimisation and selective disclosure. The application still has to decide what happens next: whether the verified attribute becomes persistent Drupal user data, whether only a derived result is retained, or whether the information can disappear once the transaction has been completed.
Those decisions sit above the wallet protocol. Drupal already provides accounts, permissions, fields, workflows, access rules, logging, and application-specific data models, but none of those automatically determine which verified identity attributes an organisation should retain. Connecting a verifier to Drupal therefore solves only part of the problem; the rest belongs to application design, data governance, and the legal requirements of the service being built.
The EUDI technical framework is still developing as deployment approaches. Version 3.0.0 of the EUDI Wallet Architecture and Reference Framework, published in July 2026, updates Wallet-Relying Party registration and introduces the concept of Relying Party Services alongside other changes. For Drupal projects in European government, education, and other identity-sensitive environments, the question is not simply how Drupal accepts a wallet, but which verified facts the application actually needs after the wallet has done its job.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Kazima Abbas wrote and curated this issue of Editor’s Pick.
