Topic Q - Interface between the User and the Wallet Instance

[phin10]

Description
The question here is whether the ARF needs to contain high-level requirements regarding the UI of a Wallet Instance, and if so, which ones. This topic is focussing on Accessibility.

Planned publication discussion paper
3 September 2025

Link to discussion paper
Link

Discussion close
Three weeks later.

[JohnOnGH]

Hi @phin10 - the answer is "yes".

We (Sezoo) are currently supporting Swinburne University (https://www.swinburne.edu.au/, one of the global design factory universities) in research on wallet design, looking specifically at the need for guidelines to provide consistent messaging and experience for users as wallets support higher risk/value/privacy interactions.

Swinburne have just finished the literature research and will be moving onto questionnaires with wallet designers shortly. We have a few good links into the wallet UX design community, but would be happy to have others proposed.

Our thinking is that we need guidelines at a high level to ensure that the experience is uniform enough that we know how a wallet will inform us about other parties, warn us about risks and help us make informed choices.

Imagine if car designers were allowed to play with which way round the brake and throttle go in a car. No-one wants wallet choices to suffer from as many (poor) design interpretations as cookie choices.

The guidelines need to be developed by a multidisciplinary team of digital sociologists, UX designers, technologists, lawyers, anthropologists, behavioral scientists etc. Think WCAG for mobile wallets.

Here's a deck we produced sometime ago explaining the rationale: (https://docs.google.com/presentation/d/1ayMoKOh3PImBaOiUHULaojQsW_1Me4rhKMnXmjaRzB8/edit?usp=sharing )

John.

[JohnOnGH]

And here's Swinburne's paper: https://apo.org.au/node/332683

[OBIvision]

Usability is a critical question. So more important NOT to dictate and preventing change and upgrades.

A wallet will have many different form factors depending on the use case and citizen. Creating structure that force mandatory top-down design is a certain way to prevent solutions to the many real problems.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicQ AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[burdges]

A wallet should display the infromation being requested by the RP and some human readable authorization statement by whatever authority approves the RP requesting that specific information.

A wallet should immediately reject any requests for infromation not authorized to that RP.

It's likely RPs need some sort of sub-RP scheme for data minimization.

[david-bakker]

@AEPDmbeltran: Thank you again for your comments.

We agree that a well-designed UI is instrumental in achieving the objectives of both the European Digital Identity Regulation and the GDPR. We also agree with almost all of the specific recommendations you do. Many of these recommendations, such as those for selective disclosure, data minimization, user approval, disclosure purposes, RP authentication, pseudonymity and unlinkability, logging, etc. are in fact already covered in the ARF, especially since these aspects are not primarily governed by the UI, but rather are functions of the Wallet Unit (or even the Wallet ecosystem as a whole).

However, the European Digital Identity Regulation does not contain a mandate for the Commission to define a common UI to be supported by all Wallet Providers. It is the responsibility of the Wallet Provider to design the UI of their Wallet Solutions. We believe that this is as it should be, as UI design is task requiring expertise and an effective UI design must take into account proper localisation. We would like to note that although this will lead to divergent user experiences between different Wallet Solutions, each individual Wallet Solution will need to be certified for data protection. This will include adherence to the GDPR and to privacy-related requirements in the European Digital Identity Regulation and the related CIRs.

In conclusion, we see no need to add additional HLRs to the ARF to cover UI aspects.

[JohnOnGH]

I disagree.

Consider if this logic was to be extended to other products that people use and that enable them to perform tasks that can both benefit and cause risks for them and those around them. Replace "Wallet Unit" with "car" and "Wallet Provider" with "car manufacturer". Now we can see that the sentence "However, the European [..] Regulation does not contain a mandate for the Commission to define a common UI to be supported by all car manufacturers" causes some concern.

• what if manufacturers could decide whether the brake or the throttle go on the left or the right?
• what if they could decide what type of device and signifier to use for braking and accelerating

Such diversity would mean that driving licenses would have to reflect the manufacturer of the vehicle that you are licensed to drive. People couldn't just hire, or buy, or drive, any passenger car, they would have to be trained in that car's "UI".

There is a sensible limit to apply here. Car drivers can cope with indicators and windscreen wipers varying, and even different ways to control the A/C and entertainment, lock and unlock the doors etc. The "display" and layout can look manufacturer unique.

The same logic hold for digital wallets. Absent common guidelines for the presentation of consent based options and the meaning/impact of taking any option, each manufacturer will design their own way and users risk being confused or making mistakes when they use a different device. Relying parties may face claims from users that they used wallet X, and hence "didn't know/realise this would happen".

Hiding behind the lack of a mandate doesn't reduce the risk here. We will need design blueprints for a few simple interactions. The rest can be up to the designer and their interpretation of "localization", culture, and (even) brand.

Swinburne University (based in Victoria, Australia) will shortly be making publicly available a research report on this topic. Happy to share a link when then becomes available.

[JohnOnGH]

Swinburne's paper is now publicly available here: https://apo.org.au/node/332683