EUDI Wallet: who asks for what from your identity?

A company asks you to prove your identity. Today, you rarely see the exact list of data it registered an intention to request, the recorded purpose of the collection or the certificate proving that it is the service it claims to be. If the transaction fails, you often leave with a generic error and almost no evidence explaining the refusal.

The European Digital Identity Wallet is designed to change part of that imbalance. The requester will have to register. The registry will have to be public and machine-readable. The wallet will have to compare the data requested with the data registered. Every transaction, including a failed one, will have to leave a log containing the service identity, the categories of data requested and the reason for failure.

Those rules do not prove that the French system will execute them perfectly. They provide something more useful than a promise: a list of properties that can be tested.

This is the eighth and final part of l0g’s investigation Your identity in your phone. Part one followed the data and logs behind France Identité. Part two measured the practical cost of alternatives. Part three examined sovereignty under contract. Part four followed age becoming an access credential. Part five tested the day digital identity stops responding. Part six followed the bill behind a free proof. Part seven measured dependence on mobile platforms.

Version française : Votre identité doit vous laisser un reçu.

Key points

From 24 December 2026, every Member State must have at least one national registry of services using the wallet. The information must be available through a human-readable website and a common API that can be queried without authentication. (Implementing Regulation 2025/848)
The registry must publish the service identity, contact details, type of activity, data it intends to request and the declared purpose for each use. (Annex I to Regulation 2025/848)
Registration is not an administrative approval of the legal necessity of each field. Since the July 2026 amendment, some use information is collected automatically for transparency without a prior authorisation procedure. (Implementing Regulation 2026/1730)
The wallet must compare the request it receives with the attributes registered in the service certificate. If the request goes beyond them, it must clearly warn the user before any disclosure. (Implementing Regulation 2026/1731)
The user must explicitly approve an excessive request. Silence or pre-ticked boxes are not sufficient. The wallet policy then determines whether the request may continue, be limited or be rejected. (Regulation 2026/1731)
The wallet must log every transaction with a relying party, successful or not. (Implementing Regulation 2024/2979)
The log must at least contain the date and time, the service name and identifier, its Member State, the categories of data requested and presented and the reason for failure. (Article 9 of Regulation 2024/2979)
The wallet provider may access those logs, where access is necessary to provide wallet services, only with the user’s explicit prior consent. Their integrity, authenticity and confidentiality must be protected. (Regulation 2024/2979)
The EUDI dashboard must let the user view connected services and, where applicable, exchanged data, request erasure and report a suspicious request to the data protection authority. (Regulation 2024/1183)
Member States must publish open, machine-readable statistics on valid wallets, accepting services, complaints, incidents preventing use, data breaches and affected users. (Article 48a of Regulation 2024/1183)
Those obligations create a remarkable audit surface. They do not by themselves create automatic compensation after a lost grant, rejected signature or missed deadline.
France Identité is already preparing three integration routes: direct OIDC, OID4VP for the EUDI Wallet and an interoperability Playground. (France Titres)
France Titres reports more than 4.5 million users and more than 80 signatories to its public-private memorandum. Those figures describe the current ecosystem, not a completed production EUDI wallet. (France Identité, memorandum)
The mobile source code is still described as forthcoming open source. The latest quantified accessibility audit found on the official website concerns a May 2025 pre-production build and classifies both iOS and Android apps as non-compliant. (Security, accessibility)

The wallet must verify the party verifying you

The first reversal happens before any data is shared.

Implementing Regulation 2025/848 requires every Member State to establish at least one national registry of wallet-relying parties. A bank, public authority, insurer, operator or any other organisation wishing to receive EUDI proofs must register in the Member State where it is established.

The registry is not meant to be an administrative file hidden from public view. Its content must be available online:

through a national website readable by a person
and
through a common API readable by a machine

The API must use REST and JSON, be documented in OpenAPI 3, allow searches without authentication and return electronically signed or sealed responses. It must be able to return current information and the history of access and registration certificates. (Annex II to Regulation 2025/848)

Annex I requires, among other things, publication of:

the official legal name and a user-friendly service name;
legal identifiers and Member State of establishment;
support contact details;
the type of service provided;
for each use, the data, attestations or attributes intended to be requested;
a description of the intended use of those data;
public or private status and any relevant entitlements;
any intermediary acting for the service. (Regulation 2025/848)

Publication must not be confused with a government seal of approval. Regulation 2026/1730 specifies that some information concerning contact details, service type, data requested and intended use is collected automatically for transparency without prior authorisation of its substance. The registry makes the declaration visible and usable by the wallet. It does not turn every registered collection into a necessary or lawful collection.

Necessity remains subject to applicable law, the competent authority and, ultimately, the courts.

The registry makes the service declaration visible. The wallet must then compare that declaration with the request actually received. Sources: Implementing Regulations 2025/848, 2026/1730 and 2026/1731.

The extra data point must trigger a warning

The European framework does more than authenticate the service.

Since Implementing Regulation 2026/1731, the wallet must compare the attestations, attributes and claims requested with those in the requester’s registration certificate.

If the certificate cannot be validated because it is expired, revoked, malformed, issued by an untrusted provider or cannot be cryptographically verified, the wallet must warn that the relying party could not be validated. The request cannot be presented as successfully validated. The user must explicitly approve it; silence or a pre-ticked box is not sufficient. (Rule WRP-VALIDATION-02)

If the service asks for data not covered by its certificate, rule WRP-OVERASKING-02 requires a clear warning before any disclosure. The message must identify that the requester is asking for more information than it registered. Approval must again be explicit. (Regulation 2026/1731)

The text does not impose one response to every mismatch. Based on risk analysis, security policy and applicable law, the wallet provider must decide whether the user may continue despite the warning, whether only the covered subset may be disclosed or whether the request must be rejected. (Rule WRP-OVERASKING-03)

There is a reason for that flexibility. Not every difference is necessarily fraud. A registration may be outdated, a new service may be incorrectly registered or an exceptional need may rely on another legal basis.

It also creates a decisive design question:

Will the warning help the user understand the risk, or become another window everyone accepts to continue?

The investigation cannot answer until the French interface, wording, permitted choices, number of excessive requests and continuation rate after warnings are visible.

Pedagogical example, not an observed case

Registered use: opening an account
Registered data: identity, adulthood, address

Request actually received:
identity, adulthood, address, diploma

Expected result:
warning before the diploma is disclosed

This example illustrates only the comparison required by law. It does not claim that a real bank asks for a diploma to open an account.

Every transaction must leave a trace

The second safeguard is less visible but may matter more in a dispute.

Article 9 of Implementing Regulation 2024/2979 requires the wallet to log every transaction with relying parties and other wallets, successful or not. Electronic signing and sealing are included.

The log must contain at least:

Date and time
Service name and contact details
Unique service identifier
Member State of establishment
Types of data requested
Types of data presented
Reason if the transaction did not complete

The provider must ensure the integrity, authenticity and confidentiality of that information. Reports sent to data protection authorities from the wallet must also be logged. Where provider access to logs is necessary to provide wallet services, it requires the user’s explicit prior consent. (Regulation 2024/2979)

The amended eIDAS Regulation also requires a common dashboard where users can see an up-to-date list of connected services and, where applicable, data exchanged. The same dashboard must make it easy to request erasure and report an allegedly unlawful or suspicious data request to the national data protection authority.

The word “receipt” in this article is therefore functional. The law requires a log and dashboard. It does not necessarily promise a signed PDF with a predetermined evidential status in every type of litigation.

The fields shown are the minimum required by Article 9 of Regulation 2024/2979. The dashboard, erasure request and reporting functions come from the amended eIDAS Regulation.

The log that protects you may also expose you

A history containing a bank, hospital, university, employer, platform and public authority could reveal a substantial part of its holder’s life, even without the full detail of each file.

That risk follows directly from the fields required in the log: service, date, time, data requested and data presented. This is an l0g risk analysis, not evidence that such a history will be centralised or already exploited. The Regulation instead requires confidentiality and restricts provider access to cases where it is necessary and the user has explicitly consented beforehand. (Regulation 2024/2979)

The French implementation should publicly answer four questions:

Where is the log stored?
Who can decrypt it?
How long is it retained?
What happens after a phone is lost or replaced?

EU law sets a baseline, while availability duration remains linked to Union and national law. France will therefore need to publish the exact retention policy, encryption method, any backup mechanism, migration route and process after device compromise. (Article 9(3) to (6) of Regulation 2024/2979)

The best system is not one that keeps no trace. Without a trace, the holder may be unable to prove a refusal or excessive request. The more demanding objective is a trace useful to the citizen, unreadable by actors who do not need it and deletable under a public rule.

Europe is creating a public audit API

The registry due on 24 December 2026 could become one of the most useful transparency surfaces in the project.

The common API must let any requester, without prior authentication, search for an organisation, retrieve complete lists and consult public certificate information. Results must be electronically signed or sealed and the schema published in OpenAPI 3. (Annex II to Regulation 2025/848)

That makes it possible to build an independent observatory without collecting user identities.

As of 28 August 2026, l0g did not identify a French production registry meeting those specifications in the official pages reviewed. This is not evidence of delay: Regulation 2025/848 applies from 24 December 2026. It simply defines what must be findable at that deadline.

l0g tool: Who asks for what?

The tool below queries neither the French registry, which has not yet been published, nor any personal data. It locally compares categories declared in a certificate with those requested by a transaction, checks the service-identity evidence and audits the receipt’s minimum fields. Enter category names only, never personal values.

// LOCAL REQUEST AUDIT

Who asks for what from your identity?

Compare the categories declared in the certificate with those requested by the transaction, then inspect the receipt left by the wallet.

local · zero transmission

Educational examples

The examples describe no real service. They only demonstrate the comparison logic.

Method, sources and limitations

Comparison is literal after typographic normalisation. Synonyms may be incorrectly flagged as different. The “stop” status is this tool’s precautionary rule, not a decision imposed on every wallet. The tool does not validate legal basis, necessity or a service’s real identity. Enter category names only, never personal values.

Public registry of wallet-relying parties primary source
Request-to-certificate comparison and overasking warning primary source
Minimum transaction-log fields primary source
Dashboard, erasure and reporting primary source

Reference checked on 2026-08-29 · model v1.0.0

Incidents must become public data too

The new Article 48a of eIDAS requires Member States to collect statistics on the operation of wallets and qualified trust services.

The minimum dataset includes:

the number of natural and legal persons with a valid wallet;
the type and number of services accepting the wallet;
user complaints and consumer-protection or data-protection incidents;
a summary report on incidents preventing wallet use;
significant security incidents, data breaches and affected users.

Those statistics must be made public in an open, commonly used, machine-readable format. Each Member State must submit them to the Commission by 31 March every year. (Regulation 2024/1183)

That does not guarantee granular categories, immediate disclosure of every incident or a perfectly comparable historical series from the first year. Definitions, denominators and publication format will matter.

L0g will seek to separate:

wallet incident
attribute issuer incident
relying party incident
device refusal
identity refusal
legitimate regulatory refusal
false technical refusal
outage without loss of rights
outage with financial consequences

A raw complaint count means little without the number of users, transactions, services and failures.

The colour shows the level of evidence, not an overall security score: established law, visible preparation, public proof still awaited or unresolved responsibility.

What France is already preparing

France Titres is not starting from a blank page.

Its page for public and private services already presents three routes: direct OIDC integration with France Identité, OID4VP integration to anticipate the EUDI Wallet, and a Playground for experimentation. (France Identité)

The public Playground lists wallets, online verifiers, issuers and conformance tools. It explicitly presents itself as a testing directory. Its existence demonstrates interoperability work; it does not prove that a listed service is approved, certified or used in production.

France Titres reported more than 4.5 million users in July 2026. Its memorandum of understanding reported more than 80 signatories in May, with the goal of aligning public and private actors with European rules and standards. (France Identité, memorandum)

Those elements show that an ecosystem is preparing. They do not establish that the current app already meets the final EUDI requirements for logs, registries, warnings and dashboards.

A European list of certified wallets

The eIDAS Regulation also requires the Commission to publish and maintain a machine-readable list of certified wallets. Member States must submit the certificate, assessment report, description of the identity scheme, supervisory regime, information on liability and arrangements for suspension or revocation. (Article 5d of Regulation 2024/1183, Implementing Regulation 2025/849)

That list will make it possible to verify that a product marketed as a “wallet” actually has the European status it claims. It will not replace the certification report, review of the exact scope or monitoring of the versions distributed.

Where public evidence is still missing

The French production registry

France will have to publish the website, API, registration policy, registrar and certificate authorities able to issue access and registration certificates. Regulation 2025/848, amended by Regulation 2026/1730, sets that framework from 24 December 2026.

L0g did not identify those production elements in the official French corpus reviewed on 28 August. This negative statement is limited to the public material found at that date.

The overasking interface

The EU text defines the required outcome: comparison, warning and explicit consent. The French layout, wording, available choices and rejection rules remain to be seen and tested. (Regulation 2026/1731)

Source code

The EUDI Regulation requires open-source licensing for wallet application components. The French security page still says that the mobile source code will be published “forthcoming”. (Regulation 2024/1183, France Identité)

For that publication to be verifiable, it should include at least:

repository and history
licence
dependencies
build instructions
software bill of materials
reproducible build method
mapping between source and store binaries
excluded components and justification

Open code does not by itself certify security. It enables scrutiny that would otherwise remain limited to the administration, contractors and commissioned evaluators.

Accessibility

The latest quantified audit published on the official page was established on 23 May 2025 using pre-production builds. It found 35.14% of applicable RAAM criteria met on iOS and 36.11% on Android, with both applications classified as non-compliant. France Titres states that the test conditions may have produced differences from the public version. (Accessibility statement)

Those figures therefore do not necessarily describe the application distributed in August 2026. In the official pages reviewed for this article, l0g found no newer quantified mobile audit. The rigorous conclusion is not that the current app still meets only one third of the criteria. It is that a new public result is needed to measure progress.

The law is more protective than the simplistic narrative

After eight parts, several written safeguards should be acknowledged without ambiguity.

The EUDI framework requires or provides for:

voluntary use and alternative means;
selective disclosure;
pseudonyms where full identification is not required;
a ban on telling attestation issuers how attestations are used;
authentication of requesting services;
a public registry of their declarations;
detection of excessive requests;
a user-controlled transaction log;
erasure and reporting through a dashboard;
open application code;
wallet certification;
public statistics on complaints and incidents. (Regulation 2024/1183, Regulations 2024/2979, 2024/2981, 2025/848 and 2026/1731)

Those properties are difficult to reconcile with the claim that the legal project was designed solely to centralise and track citizens.

They are not a blank cheque either.

A safeguard can fail in:

code
interface
certificate
registry
log
contract
phone
recovery process
alternative route
redress process

The useful level of criticism is to compare each implementation with the rule constraining it.

The receipt compensates nobody

Financial risk returns at the moment of refusal.

The wallet may be used to open an account, access a financial service, sign a document, apply for a grant, buy training, modify a company or authorise a transaction. Depending on the use, those functions are already deployed, tested or planned, as established in the previous parts of this investigation.

Suppose, only to analyse the risk mechanism, that a signing transaction fails before a contractual deadline.

The log could establish:

the service contacted
the exact time
the data requested
the data presented
the technical reason for failure

That trace may help demonstrate that the user attempted to act and that the transaction failed. It does not automatically determine:

whether the service, wallet provider, issuer or user was at fault;
whether the deadline should be extended;
whether the loss is direct, certain and compensable;
which jurisdiction has authority;
how much should be paid.

The last risk in the chain is no longer invisible. It remains legally fragmented.

IDENTITY
   ↓
AUTHORISATION
   ↓
TRANSACTION
   ↓
INCIDENT
   ↓
LOG
   ↓
LIABILITY
   ↓
REMEDY

Europe has documented much of the first five boxes. France and the relying services must make the last two understandable.

The final l0g crash test

The series ends with eight monitoring commitments.

Principle	l0g test	Evidence expected
Voluntary use	Complete the same service without a wallet	Same right genuinely accessible, with published time and cost
Minimisation	Request only an age threshold or attribute	No additional data disclosed
Registry	Search for the service before the transaction	Public, certified and historic declaration
Overasking	Request an attribute outside the certificate in an authorised environment	Clear warning before disclosure
Traceability	Deliberately fail a test transaction	Complete log with reason for failure
Erasure	Use the common dashboard	Traceable request and measurable response
Resilience	Revoke or replace a test device	Old instance blocked, recovery documented
Financial risk	Simulate a near deadline	Right preserved, contact and remedy identified

Destructive tests must use accounts, devices and environments prepared for that purpose. No real right, third-party identity or personal deadline should be endangered to produce an article.

Method and limits

This article relies primarily on European Regulations 2024/1183, 2024/2979, 2024/2981, 2025/848, 2025/849, 2026/1730 and 2026/1731, together with official France Identité pages on integration, the Playground, security, the memorandum and accessibility. The corpus was reviewed up to 28 August 2026.

Not every European obligation is yet observable in a French production application. The relying-party registry regime applies from 24 December 2026. Playground demonstrations are test tools and are never presented here as certified services or evidence of production deployment.

L0g did not access internal architecture, a non-public French registry, certification contracts, a final EUDI data-protection impact assessment, real user logs or institutional replies to the questionnaires. Documentary absences are always described as material not found in the public corpus, never as proof that the information or function does not exist.

The overasking and financial-failure examples are explicitly pedagogical. They illustrate the operation of the rules and risk propagation; they describe no real incident attributed to a named company.

Eight parts later

France Identité and the European wallet can no longer be reduced to an identity card stored in a phone.

They form an infrastructure connecting:

the State certifying identity
the phone protecting keys
the contractor building the service
the relying party requesting data
the registry publishing the declaration
the wallet comparing the request
the citizen authorising disclosure
the log keeping the trace

The investigation identified real risks: sometimes inconsistent documentation, unequal alternatives, a long outsourcing chain, fragmented responsibility, poorly measured recovery times, hidden economic costs and dependence on mobile platforms.

It also identified real potential improvements: disclosing less than a photocopy, proving age without giving a name, knowing who is asking, detecting excessive collection, keeping evidence of refusal and publishing incident statistics.

The reasonable conclusion is neither automatic trust nor automatic rejection.

European law has made much of the promise verifiable. France is now responsible for publishing the evidence.

The registry must be public. The API must be machine-readable. Requests must be declared. Failures must be logged. Incidents must be counted.

Then l0g will count them.