Wallet Requester Trust Should Not Depend on the User Catching the Problem

The wallet becomes much less protective when the system still relies on the user to catch the problem in real time. That is the weak spot running through both requester registration design and over-asking protection.

Executive Summary

• Requester trust depends on more than showing a name on screen. It depends on whether intent is encoded clearly and consistently before the request reaches the user.
• Optional or uneven registration layers can weaken harmonization and make warnings less predictable across Member States.
• A wallet that mainly warns the user about excessive requests still leaves too much compliance work in the user’s hands.
• Offline, proximity, and lower-connectivity scenarios make weak intent handling even more visible.

What This Is About

Two questions sit closer together than they first appear.

The first is about relying-party registration: how clearly the system knows who is asking, for what purpose, and with which allowed data request.

The second is about user protection at the moment of sharing: whether the wallet merely warns the user, or actively prevents requests that should not happen.

Together they point to the same design issue. The system is stronger when requester intent is explicit and enforcement happens before the user has to become the compliance officer.

The Intent Layer Is More Important Than It Looks

Small clauses in requester registration can shape the trust model of the whole ecosystem.

If the machine-readable intent layer is uneven, several things start to drift:

• user warnings become less consistent
• request transparency becomes harder to harmonize
• trust predictability starts varying by implementation detail

That is why this issue is bigger than one optional certificate or one registry field. It affects how clearly the wallet can tell the user what is being requested and why.

Warning the User Is Not Protection

The framework already moves in the right direction on paper. Requesters register what they plan to ask for. They should not ask beyond that scope. Wallets can authenticate the requester and validate the request. Users can report suspicious behaviour.

The gap is what still happens in the moment of use.

If the main control is “warn the user,” then the user still has to:

• notice the issue
• understand that it matters
• decide whether to continue
• possibly report it afterwards

That is not nothing. But it is still weaker than preventing clearly out-of-scope requests by default.

Harmonization Breaks in Small Clauses First

One useful refinement in this debate is that home-country registration rules may limit the idea of easy country shopping. Even so, the deeper concern remains.

The real risk is not simply where a relying party registers. It is whether the intent and request model stay equally strong across Member States.

That is how harmonization usually weakens first. Not through one headline rule disappearing, but through one “optional” layer becoming inconsistent enough that the user experience and trust signals stop lining up.

Offline and Proximity Flows Expose the Gap Faster

Registry lookups and live APIs can carry a lot of explanatory weight in connected online flows. They are less reassuring when the environment is weaker, more local, or more time-pressured.

That matters for:

• offline checks
• proximity presentation
• assisted journeys
• situations where the user has less time to inspect the request carefully

In those moments, clearer built-in intent handling and stronger default enforcement matter more, not less.

Trust in the Wallet Is Not Trust in the Service

The wallet can improve transparency without magically transferring trust to every relying party.

That distinction matters. Trust in the service provider still has to be earned over time. The wallet can help by making the request clearer, more limited, and more enforceable. It cannot replace the need for trustworthy behaviour by the relying party itself.

That is another reason why the intent layer matters so much. It is one of the few places where the wallet can reduce ambiguity before the user is asked to decide.

Why This Matters

The EUDI model turns legal design into real request design. Once relying parties operate at scale, weak intent handling and warning-heavy protection stop being abstract policy questions.

They will become product questions:

• what does the user see
• what gets blocked
• what remains ambiguous
• who does the work when something feels wrong

This connects directly with Approval Moments Are Part of EUDI Wallet Readiness, which focuses on trust at the moment of sharing, and The EU Social Media Ban Debate Needs an Age-Assurance Baseline, Not One Forced App, which argues for stronger baseline protection before the user faces the decision alone.

Recommended Next Actions

• Treat machine-readable intent as a first-order trust and UX requirement.
• Reduce optionality that weakens harmonized request transparency across Member States.
• Decide which kinds of excessive or out-of-scope requests should be blocked by default.
• Test protection logic in offline, proximity, and time-pressured flows rather than only in ideal API-connected scenarios.
• Keep the distinction clear between trust in the wallet and trust in the relying party.
• Design user reporting as a backstop, not as the main protection model.

Sources

• Short-post source set on relying-party registration, request intent, and out-of-scope request protection
• Comment-thread arguments on harmonization, offline use, and stronger default enforcement