I was listening to an interesting discussion between Nick Lambert of Dock Labs and Marie Austenaa, who was then the Payment Domain Lead for the EUDI Large Scale Pilots and Head of Digital Identity at Visa. These are both people I take very seriously when it comes to digtial identity and I was not disapponted by the quality of their discussion and the thinking that it engendered.
There’s lots of great stuff in here, particularly around the idea of sending money to IDs that have been cryptographically verified (I wish we had a digital identifty infrastructure in the UK so I could turn this on for my bank accounts) and the idea of forming legally-binding signatures. However, hanging over the project are consumrs fears about privacy intrusion, organisational spying and all that kind of thing. Marie suggests four “guardrails” to reassure people, all of which make sense, even though it is not immediately clear to me how they will be implemented.
- First, relying parties must have a legitimate reason to request identity data. Merchants, for example should only request data they can justify as necessary for the purposes of the transactions (not just for marketing). I am not an expert on GDPR, and perhaps one of the lawyers here can reassure me otherwise, but I assume that merchants will collect all of the identity data that they can under the general get-out clause about fraud prevention.
- Secondly, the relying parties must be known and registered. Verifiers are “expected “to be registered in a trust framework. This is the eIDAS 2.0 / European Digital Identity Wallet relying party registration and trust framework which will be mplemented nationally by Member States and will, I don’t doubt, involve public key certificates, registries and such like, defined by EU implementing acts and the EUDI Wallet Architecture and Reference Framework.
- Third, there must be mutual authentication
The verifier proves who they are to the wallet.
The wallet checks if the verifier is legitimate and entitled to request that data.
- Finally, the wallets must use selective disclosure so that users can share only what is required for the specific transaction at hand (eg, “over 18”) rather than all identity attributes.
Moving on from these sensible suggestions, though, what left me thinking after the discussion finished was something I hadn’t thought much about before: the equivalent of “cooke fatigue”. That is, there is a risk of oversharing because if sharing becomes as simple as “Face ID + tap” then the temptation for service providers to request identity, even in transactions where it doesn’t matter (except for marketing, survelliance, blackmail and so on) becomes hard to resist. Consumers will get used to just seeing some dialog box about identity and pressing OK. They won’t bother reading it and most of them won’t understand the implications anyway. So, just like they always click yes to cookies, because they don’t care and just want to get to a web page, they will get used to clicking OK and having over their personal data to anyone who asks for it.
Is this a real fear or is it paranoia?
Well, let’s start by udnerstanding what exactly cookie fatigue is. Cookies are the reference case for what happens when a legally mandated consent event is repeated at high frequency across low-stakes, high-volume interactions. Peer-reviewed studies provide direct evidence that friction asymmetry, not user preference, drives most “acceptances”. Research also shows that a binary accept/reject choice produces materially higher acceptance than more granular controls and that banner position (and language) have outsized effects independent of actual preference. In other word, users overwhelmingly engage in “satisficing” (that is, clicking through without reading) and make no meaningful choices.
Well, I hate to be that guy but the current draft of the Archtiecture Reference Framework (ARF) contains at least one design choice (all-or-nothing approval) that echoes the mechanism that experts suggest is most responsible for reflexive “accept all”. Also, with reference to Marie’s guardrails, the framework’s basic anti-fatigue safeguard of requiring the relying-party registration certificate (that lets the wallet detect over-asking) is optional in current drafts. And at a more technical level, the selective-disclosure cryptography (salted hashes over mdoc/SD-JWT) does not meet the EU’s own unlinkability requirement. In fact, the European Data Protection Supervisor (EDPS) itself has stated that the framework “does not mandate a comprehensive consent management solution within the EUDIW.”
The single most consequential design choice in the current draft sits in ARF §6.6.3.5.8: “The Wallet Unit enables the User to approve or deny the requested attributes. Preferably, the User gives approval either to present all attributes requested, or none of them” ([ARF main document](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/2.9.0/architecture-and-reference-framework-main/)). The stated rationale is that partial disclosure would leave the relying party unable to complete its service while the user has already handed over some data — treated in the spec as itself a privacy harm. The practical effect, however, is that per-attribute de-selection at the point of consent is discouraged rather than encouraged by the framework’s own guidance.
This is the precise design axis that the cookie-banner literature identifies as the single strongest lever on reflexive consent. Nouwens et al. found granular per-purpose controls on the decision screen reduce acceptance by 8–20 percentage points relative to a binary choice, and Utz et al. found the same binary-vs-granular gap independently. An all-or-nothing wallet prompt is architecturally the same choice shape as a binary “Accept all / Reject all” cookie banner — the format proven to maximise low-engagement acceptance, because refusing the whole bundle typically means the transaction (age verification, account opening, ticket purchase) simply fails, creating the same “sludge” dynamic the ICO/CMA paper describes for cookie walls. The wallet’s added transparency (requester name, purpose statement) mitigates the opacity problem cookie banners have, but does not address the choice-architecture problem: presenting a single yes/no gate around a request for, say, five attributes when only one or two are strictly required for the stated purpose reproduces exactly the “bundled consent” dark pattern the EDPB Guidelines 03/2022 catalogue names as “Overloading.”
## 5. The Regulator’s Own Admission of an Unfilled Gap
The EDPS TechDispatch draws a distinction that is arguably the most important finding of this analysis: the framework provides technical building blocks for consent but does not require a coherent consent-management layer built on top of them. Its precise language: “The current framework integrates certain technically enabled features, it does not mandate a comprehensive consent management solution within the EUDIW” ([EDPS TechDispatch #3/2025](https://link.europa.eu/BJJnnj)). In other words, per-transaction approval screens, the dashboard, and the over-asking notification are present as capabilities, but no implementing act currently requires wallet providers to assemble them into a system that actively counteracts fatigue (for example, through rate-limiting near-duplicate requests, surfacing a running count of daily approvals, or requiring a cooling-off period before repeat approvals of similar scope). This gap is structurally identical to the situation that allowed cookie-banner dark patterns to proliferate under GDPR: the legal principle (freely given, specific, informed consent) existed from 2018, but the absence of prescriptive UI requirements let market actors design toward minimum viable compliance rather than genuine user comprehension, a gap the EDPB Cookie Banner Taskforce spent 2021–2023 trying to close through case-by-case enforcement rather than upfront design mandate ([EDPB Cookie Banner Taskforce report](https://www.edpb.europa.eu/system/files/2023-01/edpb_20230118_report_cookie_banner_taskforce_en.pdf)).
The EDPS also flags a second-order fatigue risk on the oversight side: because the Regulation gives users a function to report an RP directly to their national DPA for an “allegedly unlawful or suspicious request,” a poorly defined threshold for what counts as excessive risks generating so many individual reports that DPAs cannot process them meaningfully — “it will help ensure that data protection authorities do not receive an overwhelming number of reports from users” is offered as the rationale for tightening use-case definitions ([EDPS TechDispatch #3/2025](https://link.europa.eu/BJJnnj)). This is fatigue displaced downstream: rather than users clicking through requests reflexively, they could instead flood the enforcement mechanism reflexively, with the same underlying cause — no scalable way to distinguish routine requests from genuine over-asking at the point of decision.
