Designing an European Identity Wallet: An overview of UI and UX aspects

So hello everybody. I'm Adrian Dirk. I'm from Martin Kuat, which we just rebranded recently to NSE. We are the research and development unit of commerce bank, and we initiated the ID union project and ecosystem for trusted digital identities here in Germany with the focus on EY use cases.

And today, wanna talk a bit about wallets because we also develop delici application delici wallet. And that makes me being able to draw from past experience. So we developed a wallet for the last three to four years, and today I want to talk about an aspect or about a topic, which will touch everybody of us because in 20 20, 24, the European commission within the revision of the Ida regulation will mandate every member, state of the European union to offer a European digital identity wallet. And as a user, it touches everybody of us. We all want to use that.

We all want to be able to access digital services. And then the question obviously arises, how will we interact with these services? What will be the interface? How will it look like and what will be the user experiences? So that's the topic of my talk today. That's what we will take a look into. So first up, what is the European identity wallet?

I think hopefully all of you are aware of the Ida's regulation, which basically regulates how we make trusted interactions between different stakeholders within the legal frame, within the European union, between different member states, between different stakeholders and the European identity wallet. As I already said, it will be may available by the member states and 2024 and use the citizen. You can use it, you don't have to, and it enables identification of citizens, but also authentication.

So the log in services to log in, Porwal from different kind of stakeholders from the public, but also the private sector. It will enable verification of organizations so that you know who you're talking with as a citizen, is it really my bank? Is it really the public entity I want to talk with as well as the reception, the management and the presentation of verifiable attributes to other third parties, the creation of electronic, electronic qualified, electronic signatures, and an overview of which kind of aspects of my identity did I share with other third parties?

How did I use it in the past as well as in general use cases from the private sector, which right now is not the case for the IDAs regulation. So this will be very interesting to see this development as, as well, the information, the basis of information, why is somebody asking me information? What is the legal basis?

What, what is their right to ask me for this information? I think the list will be still longer. So this is just some aspect of it. There will certainly be more aspects of what this wallet will do and enable. So what kind of core process do we have? Obviously the credential issuance is a big topic in terms of want to know, okay, who's issuing me that credential.

Is it, is it my university? Is it my bank? Or what kind of stakeholder and what's inside, what are the attributes, which I get attested here when it comes to the presentation of these attributes. I also want to know who's asking, but I also want to know why they're asking in terms of the legal basis, as well as the, what they're doing with data, right? The constant part of it. And obviously I also want to know what kind of data they wanna ask in terms of, from which credential are they asking? Is it my regulated ID? Is it some self tested information or something else?

What attributes will they ask for me? So they might not ask for all the attributes within a credential and also what kind of thresholds they might ask for, for example, in some cases, if you buy alcohol or tobacco, it, it only necessary to ask if you're 18 or older, not when you're been born or where do you live. Right. So thresholds can also ask for, and now we wanna take a deeper look into the different UI aspect of it. For example, here, how attributes are presented in different kind of wallets.

I took a look at around 15 to 20 wallets and we will take a look at different different applications. So here BECI, for example, you see an overview there exactly. See with whom you have shared these applications with. So the history of your shared interactions or activities at delic app, we see, okay, we have illustrated as this kind of ID card, as well as attributes below. And I current wallet, you have it here within other other applications where you can also see your profile and in the Irma app, you have it also as cards.

And you see here, there, there are like this card stacks, which you might be familiar with your wallet, which you can swipe through in terms of relationships. Those are question like how, who am I talking to? I want to have an overview of, of my interactions and some refer to these as connections, some as contacts, but in the end, we're talking about relationships, which we have a third parties.

So we see a common pattern here between twin, for example, and Lucy wallet will say, okay, we have, on one side, you have the credentials within the wallet and you have the context, basically your connection connections we were talking with. So you have kind of these two, two aspects of the wallet, which you can switch from the left to the right, and then the contacts or connections, however you wanna call it. Are there illustrated as a list that you can see, okay, who did I interact with?

And there might be listed chronological alphabetically or, or something like this only, only connect me wallet is doing this kind of sphere where this kind of, yeah. Also the connections are there illustrated. And how do they actually add a credential into the wallet here? You see different applications, which at the first glance, if you take a look, how they, the terminology is, they're all different. So one talking about at credential, the other one about at cards credential offer or, or the Iran about data agreement.

So there's no really a common pattern regarding the terminology, which we use here. And you see here, okay, you see the organization at first, you see, okay, this, this organization is not yet verified, but you see what kind of information credential they offer with what kind of attributes at Iran similar. They have the data agreement policy also in their, which is obviously very interesting aspects. But in the end you have this kind of credential illustrated with the attributes and the, the content of the attribute inside a illustrated, which you can accept.

Then Another very important aspect is the whole topic of use case and credential discovery. So imagine you have the wallet, you just set it up, you maybe included your ID card and derived it from your national ID card.

But, but then what, what are you doing with it? Do you know what services offered and supported? You probably won't because why should you, so we need some, some framework within the wallet, which enables the user to, to access the services without doing research. If my bank, if my telecom provider, whatever actually supports it. So here from Disney wallet, you can see, okay, I can add my verified email, my verified phone, or selfie similar in the I wallet.

But hex ID here goes, for example, a step further and says, okay, we have different use case clusters, like the e-commerce health and so on. And once I go into the cluster, I see, okay, there, the different kind of companies which offer different kind of services, which I can access within my wallet and your example for the ID wallet, they also make it possible to say, okay, here you see the ID card, it's called fuel shine.

And, but it's gray basically. So it's not some active credential, but it's indicating, Hey, you, this credential can be here. Why not? Why not choose it activated yet? Which is also a nice feature indication for the user. This could be here, but it's not activated yet. And then how you, how do you share information? Right? We have the credentials now in the wallet. We know what we can use it for. We go to the service and now we want to share information to access some kind of service, meaning that somebody's requesting information.

So we obviously want to know who in this case, for example, list wallets, commerce bank, and now we can see, oh, nice. They're verified. I really know, see, this is really the commerce bank. This is really my bank and not somebody else, which might be an attacker for land party. And then they see, okay, what kind of information are they asking for? They ask for my credit card.

And I see, okay, what kind of attributes are on my credit card? If a Disney wallet we see in additionally, they have a privacy notice. So they see, okay, how is my data used? And they also have the terms and condition in terms of why is this data asked? What is the legal basis behind that and what is done with my data? And you see my nice selfie image here, my verified picture here, Iran, they call it a data agreement. A nice feature here. Interesting feature here is that you can click on the I, so the third picture, the Iran, the I on top, and then it blurs the data.

I'm not sure if, if that's something which I want take into consideration as a user, but it's an interesting feature which you also can use. And then going the deeper into the topic of content. Then you can see here, for example, you have to approve it first here, the Disney wallet. For example, you go into the terms of the condition you go into the privacy notice can take a look, either go, either provides the link, which you further can see on a website whatsoever that you can read the privacy information or it's written there.

But obviously most of the time it's super confusing in terms of super length, the privacy notice. So we, as a community, as a society, we need to find a solution to make it actually possible, to make it comprehensible as a user, nobody reads 10 pages of privacy, privacy notice accessing, accessing some kind of service, right? So we need to make it understandable for the user, a nice feature.

What the Irma app also offers is that they can have a selective disclosure in terms of the user can choose it, that they can say, okay, are they asking me a, for certain set of credentials and attributes, but I can say, okay, maybe I don't wanna share information a, but I want to only only share information B and C what they requested. So that's also a very nice feature.

And then we also can take a look at the history of shared information, which is also asked by the reference framework here in the Irma app, you see the listed view, which is then every interaction, every action I had with a contact in the past, seeing with who did I interact with and what kind of information did I share, but then there are actually two parts of it. One is the credential credential based history. One is the contact based history.

So I can say, for example, I, I don't take a look at my tribal license and I wanna see with whom did I share my tribal license with, is it car rental person? Is it the police officer, which asked for it and so on, but I also have the other perspective to say, okay, a contact based history.

I, for example, take a look at my bank. What did my bank ask me for information? And they might ask for ID ID card, the K for KYC processes, but they have might also have me ask me for other information. So they're the two sides of this aspect of, of a sharing history. And tri for example, goes a bit further in saying, okay, this is, this is a two-sided communication in terms of receiving information and sending information illustrated kind of as a chat feature to say, okay, you got, you got ask information, did you share information? It's also then impossible to illustrate it like this.

And yeah, as I told, as I mentioned already within last three to four years be developed wallet. And that's where I draw most of my knowledge from, from the MVP to product being, for example, here in the first picture, in the first screen, you see, we, we had this kind of bell on the top, right? So every time there was an interaction, an activity happening, we, there was a bell and a notification. Then you get a notification, somebody ask you for information or you sent information, but obviously that's not how the user flow should work. So we decided, okay, let's split it up.

Let's split it up between connections and credentials, the wallet and the contacts, and then illustrate all the credentials there and also get new credentials offered directly into the wallet. Why not? But then we also realized getting a credential is such an important activity that it deserves the full attention of the user, the same with information request, meaning that we, we decided, okay, we still want to illustrate it there, but not the whole credential that you cannot accept it within the wallet.

So to speak as illustrated in the second screen, but you need to go to a separate page where then only the credential is, and you can add these credentials, see what kind of organization, what kind of attributes and so on that you really there's nothing else the user is distracted with. So that's an also very important aspect of, of the, how to design this product. And by testing these different kind of wallets also want to share like what my, my feedback is in terms of where we answer community are. I think we, there are a lot of really good apps out there.

And we taking a look at all of them. We can draw really fantastic conclusions and all of them has really nice user experience, features Harvard as a community, as a whole. Obviously there is still room for improvement, meaning that, for example, I wanted to test a lot of applications also from Switzerland, from France, from the Canadian and so on, but I wasn't able to, because they require me to derive my E I D within the set process. But obviously I have, I don't have an ID card from, from Canada or under member state. So I cannot test it.

I, I cannot take a look at it and get a feeling what the app is all about. So making, making it mandatory to, to derive your ID within the set process is hindering you as an application to get more, more people. Some people may say, yeah, I have the ID card, but I don't trust this app yet. I don't know what, what I can do. Maybe I can derive my ID card and then what they have no use cases.

I don't, I want, I wanna take a look first, get familiar, maybe test the demo or whatever. And then I derive my ID card, make it possible to build trust in the application first and then give the option to derive the ID card, not the other way around. And then also the whole topic of GDPR rights. Obviously the type of content that we say, okay, we give you the information, how we use the data. Why do we ask for the data? But that's only part of GDP power rights, right?

We, we also have the right of erasure and article 17, but who's exercising that who did exercise this right? Once in his life hand up, okay. We have four hands here, five, five hands out of 50, 60. So let's be honest. We are extend the experts.

We, we are the people who should use this rights and make use of it, but we don't because it's just not convenient. It's just how, right.

So, so we sh we need to make sure that the rights which we have, which are enshrined in the GDPR are also, you make usable and exercisable for the people, right? So the right OFIA just as one example, and this is basically missing in all the applications. Also very big topic is a topic of consent.

Some, some applications included already, but there is no standard for it. And there will be a session today later, which is with the name there. We have no consent about content, right? There's no consensus about content.

And, and that's the point. That's really a big problem, which we face in our community in which we need to standardize, because this is something where the vendor is not really should be better than one vendor. It should be standardized across the board period and something which you also noticed. And sometimes it's really easy to confuse if you actually receive an information or send information because they're, they're visually in indistinguishable. So we also should distinguish it.

If somebody receives information or sense the information, and to a certain degree, we also need to standardize, for example, the terminology, the user flows and the illustrations of the main activity in the apps. Obviously this is kind of a difficult topic because you want to have the member states and the vendors to, to have a certain kind of flexibility, to adjust their products, to adapt to user needs.

However, if we use different terminology and different wallets, use different kind of user flows or illustrations for the main features like receiving as information and sending information, then we confuse the users and it will not be easy to, to say, okay, I switch from Roman application from one wallet of one member state to another wallet offered by member state, or even if a member state offers more wallets that to go from one wallet to another wallet within the same member, state, as long as these process will be super different, we will confuse the user.

And in terms of the user experience, there are also some challenges. For example, if you use your mobile phone and open a website to access a service, then you can press, then you can press a button and your wallet opens and you get the request in the wallet. Nice. But what happens if you're on desktop and you want to access the service and you have your wallet on your phone, you scan a code. If you have an email, then it's a link.

So, so we have different kind of options, how to start this interactions. And we need to, to make sure that whatever option we use, that the, the, the customer journey and the user experience is more or less the same. And it's good for it. Then we have the data subject. This might be represented by a guardian. Meaning that, for example, if I offer a service for, for kids, then obviously I'm not necessarily talking for to the kid, but I'm talking to the parents.

And this might be also the case with people who are dependent, if they have Alzheimer or any other status or situation where they cannot really yeah. Represent themself, but there's somebody else representing them. That's we don't really have a legal structure for that. Right now we have, don't have a framework for that. So that will be also big challenge, which we face. And we also, also, they have the whole topic of credential discovery.

So what is if I access the service and they ask for my bank information, but I haven't derived it yet in my wallet, where do I get my bank information from? Does my bank even offer that?

And when, where, even if they offer it, where do I get it? So we make it be, once we ask information, the user does not have the information, the wallet yet. We need to enable the user to discover this information and get it from somewhere. We need to tell them. Then also the combination of regulated and unregulated credentials will be a challenge in terms of the regulation ID cards, for example, an unregulated the employee pass, because some, some users might, might have the need to say, okay, I want to differentiate.

I want to have like the private credentials on one side and credentials from our work on the other side. And also my last point, the, the tall topic of making it usable for people who have, who are not as privileged as we are, they might be visually impaired.

They, they might have other yeah. Problems to access the wallet. So there are, we need to make sure that we include everybody, regardless if, if they have the full capabilities that we do so that everybody can participate. And that we actually come up with a system and processes that benefit everybody, not only some privileged from the society. So I think that's something which we face as a community, but I think we will be able to, to come up with solutions. That's it from my side, if you have any further questions, feel free to reach out for me. Thank you very much.