Experiences from building the German National EUDI Wallet [Intermediate]

Perfect, let's get started. Thank you everyone for being here. We're from the German National EUDI Wallet team, me and Paul. So there are a lot of team members from our project at EIC and each of us are focusing on different things. Paul and I today will mainly focus on lessons learned from building the wallet because we are from the wallet development team whose responsibility is to build the wallet.

And basically what we're trying to focus on today is, as you know, you all expect the wallet with highest, best security, best privacy protections, best UI, UX, being scalable, not failing, supporting 80 million German citizens, right? So how we want to get there is the focus point of today.

So yeah, my name is Kristina. I'm the product owner of development team with SPRIND. And my name is Paul. I'm a digital identity expert working at the innovation department of Bundesdruckerei GmbH. I'm working as an architect in the multi-military team. You're not the architect.

Right, we have a lot of partners that help us build. So SPRIND, German Federal Agency for Disruptive Innovation, is building the wallet on behalf of the Ministry for State Modernization and we obviously get support from Bundesdruckerei, BSI, Pfandhofer, PwC, Mehen, Mehe and a lot of other folks. As you all know, the wallet comes in a really restricted solution space. What's important to note is for Germany, this is not just a regulatory exercise.

For us, it's not just going through EITS 2 requirements and checking the one by one. Our goal is to actually have a product in the market that improves digitization and improves lives of German citizens, right? Having said that, we do have certain obligations, interoperability as a member state. So a lot of functional requirements do come from regulation. And as you all know, their requirements still evolving, timelines are tight. So how do we do it?

Yes, thanks. I'll take it over. So as Christina said, I picture my job as an architect mainly to find the right balance between security, privacy, scalability and UX. And we have a lot of people that come with a certain perspective. We have the BSI that want like the highest security. We have folks from the civil society like Chaos Computer Club and they want the privacy. But the reality is as soon as you pull one of these parameters, the other ones are moving as well. And you can't look at them like just in scope. You have to see them in combination. And that's what what I do.

And to look a little bit deeper here. So security, I think, is pretty clear. If this thing is not secure, it will fail right away. We have very high security requirements, even from the IDAS legislation with the level of assurance high. We need to certify wallets. And of course, in Germany, the BSI will have some additional requirements for our wallet. We have privacy.

As I said, especially in Germany, we have a very strong civil society community that really looks about what we do here. We have data minimization and selective disclosure already originating from the requirements of the IDAS legislation. And of course, we have GDPR on top. We need to build a wallet that is scalable, especially also in Germany. We have the highest potential user base. So we have some more scalability issues or challenges compared to other countries. And of course, all of this only flies if the user experience is really good and people really want to use it.

And it's like a smooth user experience, which is also challenging because the app will be used by elderly people. It will be used by young people. And having a user interface and a user experience that works for everyone and is thrilling is quite a challenge. So what do we do?

Security, of course. We have a security-first architecture. We have defense in depth. That means we don't have a single point of failure for our security. If one thing breaks, that doesn't mean the system is broken. If you break into the backend, for example, that doesn't mean you can compromise our wallet. We have risk analysis and threat modeling, of course, because we want to achieve a level of assurance high. So we do a lot of theoretical work in the back to assess what attackers can do and what can we do to prevent that. And we'll go through wallet certification.

Of course, we do pen testing and also we'll launch the first bug bounty program by a German official ministry. For privacy, we will build the wallet in a way that we minimize the data that we know about the users. So the wallet provider will not know the user's identity. We don't have the email. We don't have the phone number. On top of this, we will block requests that are over-asking. And we offer the users a very easy option to report potential illegitimate behavior from relying parties to the data protection agency. For scalability, of course, we'll have geo-redundant data centers.

We do extensive load testing so that all of this works reliably with high transaction volumes. And for user experience, we're continuously doing user tests with real citizens. We're also exchanging with other member states. Netherlands has done an amazing job on user experience. And we have Netherlands has done an amazing job on user experience studies that we benefited from. We look into accessibility. How can we make the UDM wallet also usable for people with disabilities? And we have a sandbox that other people from our project will talk about. So I don't go into deep details here. Yeah.

So our approach is we're trying to be as transparent as possible. We have an open consultation and development process. We have public documentation. And in the end, our source code will be open source. And we just try to engage with the community to make this a successful project. And to illustrate one of these challenges that we have, bringing these four requirements into perspective, is what do we do if the user lost his device?

So implementing ACT also requires this functionality that basically if the user loses his device, he must have an option basically to call the wallet provider and say, hey, I lost my device. Can you please revoke this? So this means we need an out of band mechanism that we can authenticate the user if he lost his real device. And we've been looking into this. And here you can see how these different properties then outweigh each other. We've discussed like a revocation code that would be like a random string that the user just presents to revoke this. We have the EID pseudonym.

So this is what we can use from our German EID card that has a pseudonym functionality that we could use to authenticate the user. We have pass keys, and we could use Google or Apple ID. And all of these have benefits and disadvantages. For example, the EID pseudonym would be very secure because we use the EID card, which is already a level of assurance high. It is very privacy preserving, but it would require the user basically to tap the EID card during the wallet activation, which is not that good from user experience.

And it's also quite an additional burden for the wallet provider to maintain this. If we look at Google and Apple ID, that's a super nice user experience. Everyone has used a login with Apple and Google, and everyone has that because we have an Apple or like a Google and Android app. So everyone would have this. And the maintenance, the implementation cost would also be quite low. But of course, this is like a central IDP. It's not quite in line with like the principles of a decentralized identity wallet. So all of this, you see, it's not easy.

And as a little spoiler, the first option that we'll go live with in January is the first one, the revocation code. So there will be a randomly generated string that users can store anywhere they want. We'll offer some options, for example, putting it into a PDF where they can store it in their password manager.

Yeah, and that illustrates one of the lines in our argumentation, how we get to our decisions. Yeah, and we really wanted to show you the previous slide. And the important thing here is that every single major decision we made for architecture and how we build the wallet goes through that process that we call decision records. Every single new decisions we make, we list multiple options that are available and we evaluate them based on security, privacy, UI, UX, scalability, implementation cost.

And we see what the trade-offs are there and taking into account German citizenships, requirements, timelines, and everything, we make a decision. That's literally how much effort we put in progressing every single feature in the wallet. And that's why that also really helps us being transparent, right? Because we did a Reddit AMA.

Literally, we went on Reddit and be like, guys, give us any questions you have. And we got, I think, over 300,000 views, over 300 questions. And we can answer really easily, right? Because we have these decision records. We can stand behind these decisions. And if you point out that we missed some considerations or whatever, we're happy to reconsider, right? If we missed certain factors, whatever, that additional input that influences a decision. But I wanted to show you is the wallet onboarding, because I think that kind of a combination of us trying to balance multiple things.

So basically, after you install the wallet, that'll be the first screen you see. We're working with professional design agencies, and they're giving us illustrations right now.

So, you know, they're conditional to ministry approval, so you don't see them yet. But yeah, here is the description, explanation of the wallet, what you can do with the wallet. Let's get started.

So first, we will check whether platform authentication is checked in the background. So we don't force the user to do it at each wallet startup, but we do need the user to have it turned on.

Obviously, we need users to read the privacy policy on terms of use, how to protect the data. And then security notifications, also very important. We do have a feature where wallet provider is constantly monitoring the security posture of a device. There can be a scenario where wallet provider is revoking the device. So in that case, we need to notify the users, but it's an opt-in. And this is the part that Paul just talked about. In case users lose a device, you can revoke your wallet.

And here, the revocation code that we just talked about, there are multiple ways how you can save it. I saved it, and that's onboarding. And another important thing is, I don't know if you've seen online, but we do not collect email address. You don't need to log into Google account or Apple account to start using the wallet. What you just saw is literally everything you need to do to start using the wallet.

Okay, back to you. Second thing that we wanted to illustrate is basically another trade-off, where we have, on the one side, very high security requirements for the PID, and at the other side, this brings some disadvantages for user experience, privacy, and scalability that we maybe don't want for all the credentials. So what we'll do is basically that we say, for the PID, we will reuse a remote HSM. That gives us the high security that we really need to fulfill level of assurance high. But we know that using a remote HSM is not the best for privacy, and also not for scalability.

And also, the user experience isn't as nice, because the pin to unlock this key is a six-digit pin, so there's no possibility to use biometrics for this, because it's stored on the remote HSM. But to not basically have all these disadvantages for the rest of the functionality, the EAAs that we'll have in the wallet will use local keys from the secure key store, so secure enclave for the strongbox on the device. That's much better for privacy, that's much better for user experience, so for most of the credentials, users will be able to use biometrics if they have that enabled.

And also, that scale is much better, because then we only need to use the remote HSM for the PID. And that could bring us to a short demo of how this actually looks in our current implementation. How many of you have seen the demo terminal wallet before?

Oh, that's not that many. Beautiful. So this is a live demo with no mock-up. This is using real keys in a remote HSM. And we'll use a demo card, the famous Erica Mostaman, to initialize the PID. Let me get the screen share.

Hang on, something's frozen. Okay, so sorry about that.

Yeah, so this is the German national wallet. The branding and everything is as recent as it can get. I'll start, I think one important thing, let me start with issuing an EAA, right? So not the PID, the EAA.

Let's do, let's get a diploma, yeah? We have a lot of, I think, university use cases being presented at the EIC.

So here, I would like to get a diploma. I'm at the university website. I'm going to open it in the wallet. Here on the credential, I'm about to get issued. Here's the issuer. And I want to, this is the authorization code for us, so user need to authenticate. I'm the famous Erica. I always mistype the password. Fat fingers.

All right, so as Paul explained, we're using local key storage to issue, to bind the key. So it's not using server HSN for key storage right now. And as you can see, the university diploma has been issued into the wallet. So that's the EAA. And what I'm trying to illustrate is you do not need to issue PID into the wallet to start using the wallet. You know what I mean? It's actually pretty significant. You can start getting university credentials, like whatever other membership credentials you want into the wallet without having the PID.

So if you forget the EID card PIN, you're not blocked from using the wallet. Now let's get the digital version of this, the highest assurance magical credential.

Yes, EID card is available. This card comes with a PIN for those who are not living in the EU. So in this case, card PIN is set and known. If you don't, you can set it in the wallet. So I agree, and the issuer is Mr. Gray. And these are the data that will be read from this card. So I agree to letting the PID provider read the data from the card. And now I need to tap and hold the card against the phone. And if you ever try it, you have to keep holding. Don't just tap and release. And that was what they typed previously was EID card PIN.

Now I need to set the wallet PIN, also what Paul explained. This PIN that I'm setting right now allows to authenticate the mobile to the backend. And this architecture is our biggest defense against the biggest threat we're trying to prevent, which is impersonation of the user. And basically what it means is just stealing the device is not enough. Just knowing user's wallet PIN is not enough. Just hacking our backend is not enough. You have to combine all those multiple things to be able to successfully impersonate the user.

And even if you do that, because the data of actual PID is stored only locally and keys are in the backend, you need to like bind them, right? Like which right keys to use. So there are a lot of protections we're putting in. And also documentation is publicly online. So you can read and comment. But now we got issued. Let's do the presentation, right? Because we want to be able to use these credentials. Other two scenarios. One is age verification is a thing that is hot topic right now. In Germany, we plan to use PIDs for age verification.

So we will not be having a separate age verification credential, at least in the beginning. So this is the verifier. And then other privacy protections we're having. We are not displaying this screen to the user if we cannot authenticate the relying party. And if the relying party is over asking.

And yes, it will limit the relying parties to being able to register in Germany or in the EU. But that's a starting point. And so age over 16 is the...

Sorry, I see it on my screen. It's not being updated.

Yeah, okay, you see it now. Age over 16, the one attribute being requested. Selected disclosure, as we talked about. So you're not sharing into our PID data set. So because I'm presenting the PID, I need to type this wallet pin to confirm the presentation as a user consent and user authorization. And I successfully verified my age that I'm over 16. And another use case that potentially is also very powerful is presenting PID with something else, right? So let's say I'm applying for a job. I want to present my PID to prove my identity and my diploma to prove that I actually graduated, right?

Again, open up the wallet, successfully verified. And so you see two credentials are being requested. So all attributes from diploma are being requested and six out of the PID are being requested.

And here, because I'm presenting the PID, I need to type the wallet pin. And I also need to do a biometric check because I'm also presenting a diploma, right? And then I successfully presented and I can continue. So and we have a sandbox where we're successfully testing all this. Back to our slides very quickly. Skip this part very quick. We'll talk about this though. Maybe the very last one because we're running out of time. The third important thing that we wanted to highlight is coordination. Coordination with other and communication sharing experiences is key and takes a lot of resources.

Yeah, especially because there's so many interdependencies. The standards were developed at the same time. We're like implementing acts are still running. We have the ARF. We're based on the reference implementation. Everyone is pointing to each other and like depending on each other and therefore like communication is absolutely key to move this forward because everything is moving at the same time and the deadlines are so sharp. So that's one of the biggest challenges that we face. And with that.

Now, quick teaser on Conrad and Dietmar. Right after this, we'll talk about sandbox and we'll have a talk about accessibility because we do talk a lot about inclusion and research there.

Tomorrow, we do have other talks about relying parties. The mission of our project is not just to build the wallet, but to build the whole ecosystem, right? So we'll talk about that. And with that, thank you for your attention.