A product team may first see a digital identity wallet as another sign-in method. That framing is understandable: the visible journey begins with a button and ends with an account or service decision.
The first design question is not only how to connect. Before integration, a service owner should distinguish the intended journey, legal and technical roles, minimum attribute, evidence assumptions, data handling and selected rollout context.
Fact: what the source record supports
Regulation (EU) 2024/1183 is the official legal instrument amending the EU electronic-identification framework. Article 5b addresses relying parties, including registration in the Member State of establishment and information about requested data and its reason. The current EUDI Wallet technical materials are supporting context rather than the Regulation itself.
The Regulation and technical materials should not be collapsed. Neither determines from general context whether a particular service is a relying party, may request an attribute, is eligible, must use a wallet, has a particular liability position or is live in a selected Member State.
PARAVEILUX inference. The hidden variable is role. A team may collect an attribute because an interface permits it before recording why it is needed, what decision it supports or what happens when the evidence changes.
Action: start with the decision journey
Describe the user’s purpose in ordinary language. Which service is requested? Which decision must be made? What minimum fact is needed? Who requests it, who supplies it and who relies on it?
Then map the attribute and evidence path. Record the attribute, source or issuer as presently understood, assurance assumptions, disclosure route, storage or non-storage choice, access, retention, failure route, correction route and user explanation. Keep legal role, technical component, business owner and data purpose separate.
Finally, set change governance. A new Member State rollout, legal or framework version, trust-list or issuer change, sector rule, changed purpose, additional attribute request, storage decision, revocation event or failed presentation should reopen review.
Some narrow, well-understood integrations may need a lighter record. A detailed architecture still cannot establish lawful purpose or legal role. Conversely, legal analysis may depend on technical facts that are not yet known. The record should expose that dependency rather than force an early conclusion.
Signal: signals and counter-signals
Signals include requesting every available attribute; a technical field with no documented business purpose; storage as the default; an undocumented issuer or assurance assumption; no route for failure or correction; or the architecture framework cited as though it were the law.
Counter-signals include a bounded purpose, minimum attribute set, role map, source and version record, privacy/security review, failure journey and change trigger. They improve implementation discovery. They do not establish eligibility, lawful processing, role classification or liability.
Owner Q&A
Is every service that checks an attribute a relying party?
The answer depends on the selected framework, implementation, sector and facts. This article preserves the classification question; it does not decide it.
Does a wallet attribute prove the underlying fact forever?
No such conclusion is supported. Record issuer, time, context, assurance, revocation and correction questions appropriate to the service.
When should technical design pause?
Consider pausing when role, purpose, minimum attributes, lawful handling, trust assumptions, accessibility or failure route cannot yet be stated clearly enough for a bounded decision.
Limitations
Relying-party classification, wallet availability, mandatory use, eligibility, attribute entitlement, legal basis, consent validity, liability, national implementation, sector requirements, assurance level, issuer trust, retention, accessibility and integration security are Not assessed.
Next verification
In the EU framework, a service considering wallet use can first ask which role it would take, which attributes it needs and why. The answer can depend on the Member State, sector, service, user population, current technical materials, data handling and evidence.
Sources
- Regulation (EU) 2024/1183 — official EU amending Regulation; Article 5b provides the bounded relying-party context.
- Current EUDI Wallet technical materials — supporting context whose version should be checked for the selected implementation.
Do not include wallet presentation data, identifiers, trust credentials, test accounts or architecture secrets in public copy. This is general risk education, not professional or certified advice. The source describes a bounded EU framework; whether a comparable issue can arise for you depends on current rules, Member State, sector, service, role, data and evidence.