Introduction to the German EUDI Wallet Project

So you can differentiate us. I'm Tosin. I work for the German Federal Agency for Disruptive Animation. And I'm Paul working for bunga. I am the German Federal Printer's office. Yeah. And we're here today to present you the latest update, the latest information about the German EID wallet project. Thank you very much. And you see we are a team. We work together. Thank you very much. But the clicker doesn't work First. Yep. We need to fix that.

Yeah, so the team, oh, Now we have the next slide. We just have to do the right, sorry.

Okay, thank you very much. So let's, let's start with setting the stage first. So our basic assumption is wallets are there, right? So how many of you use a wallet on the smartphone to pay daily? Yeah.

So, and going forward or all already right now, we are also storing credentials in the wallets, right? Boarding passes going forward, also identity documents, driver's license and so on. So that's gonna happen. So why do we need an e Does regulation then? And the answer from my perspective, or what our perspective is, as so many data are flowing in through the system, we somehow need to make sure that this data is handled properly and users aren't protected.

So, and that's, that's the aim of the, of the IDA regulation, to protect user data, to make sure access to wallets and infrastructure is non-discriminatory. So that not one, one wallet provider decide what credentials you can put in your wallet and under what circumstances. And that all those wallets are inable. That's a key aspect. And the other aspect is that the I regulation is a blueprint And a rollout plan. So it lays out what services need to be available, what infrastructure needs to be in place, and there need to be wallets.

And the member states are obliged to provide their residents with wallets by end of 26, early 27. That's subject to an ongoing negotiation I would say in Germany, we have started a project, the Ministry of Interior and Community has started a project in cooperation with the federal agency for disruptive innovation that aims at developing the concept of the German EUDI wallet ecosystem that shall be an integral part of the overall ecosystem of the European Digital Identity Wallet.

And the objectives of that project are, we would like to understand the challenges and the potential that are associated with this wallet based infrastructure because that infrastructure is needed for the digitization of our society. And especially Germany right now isn't really a leader in digitization, but we have ambitions, right? And so we would like to, to figure out what do we wanna achieve? What are the use cases, what's the playground basically? And how do we ensure that it's gonna land? It is embraced by the community, right?

So we as a nation are typically a bit hesitant to embrace change, right? To embrace new things. So we wanna make sure that's gonna happen and we want to figure out What must be provided by the government or by the public sector and what can be left to the market. There's a lot of room in the regulation for example, for who's gonna provide the wallets for example. And we would like to figure out where's the boundary and what are the incentives? There's some starting conditions for us.

So to start with, we take the regulation, we take the A RF, and we design a system that fulfills the need, the needs of our society, of our nation to start with. We don't like unique persistent identifiers, right? So that goes back in the history. But it's something that is important for us and we have a decentralized ERD ecosystem if we would like to keep it that way as decentralized as possible, and resilient even in the case of a political change. And we have a federal structure.

So we've got the, the federal, the federal government, we've got the states, we've got the municipalities, we have more than 11 of them and most of them today are issuers. They issue driver's licenses, they issue IDs, cards and so on. So we need to keep that in mind that we need to incorporate that in our design and We want to be in trouble, we want to be in trouble with the rest of the European Union and even beyond that. And we want to develop a concept that is feasible by taking into consideration security privacy. That's clear.

You're expecting this from us, but we also would like to build something that is usable and that has a reasonable user reach. That's what we are not so good in or at at least haven't been in the past. So we would like to get better about that. So we'd like to figure out what's feasible and what not. And we would like to evaluate the concept we are, we're developing. So this is the kind of a timeline and the structure of the overall project. So there are a couple of different activities and we will guide you through those activities in the course of our presentation.

And we are strongly cooperating with the large scale pilot potential. So in the, in the lower part, you see our project in the upper part, you see the LSP potential, whatever we are developing concept wise, software wise is being provided to the LSP. And we are concept exchange and wanna test and evaluate our ideas. And the concept shall be completed by mid 25. And it will incorporate not only technical aspects but also what is needs to be done on the governance angle, in the legal angle, business perspective and so on.

It shall be a comprehensive concept and that's why we have an interdisciplinary team at Sprint and with other parties that works on that. And we are working with the society. So we are working with people from civil society, science, private sector, and if you want to chi in, it doesn't matter whether you live in Germany or someplace else, whether they are German or other nationality, we are eager to get your contributions. So that's why we have this open, transparent consultation process.

And on the right hand side of this, of the of the slide, you see the QR code that brings you to a location where you find where you can find all our documents. So everything we do is published publicly and you can raise issues with art with us if you see if this is an error, if you have an idea whatsoever, let us know. And we are also engaging with the, with the community, with the society to workshops for example.

And we have put, we have more, we have, but we have shifted the focus more to online, online formats like open consultation hours because we feel that is more inclusive, it's easier to attend even from different geographies. So we have a couple of open consultation hours in architecture. We recently had a workshop on privacy and going forward we will also set up a working group working on operating model and business models. And we also directly approach relevant parts of the community and have interviews with them. Do they know about wallets? What do they expect from wallets and so on. Yeah.

For the next part of the presentation, I would hand over to Paul. Thanks Ersin. So the second pillar of the German wallet project is the world architecture proposal. And I'll guide you through some information on this. The architecture proposal is a document that describes the specifics of the German EUDI wallet, how we envision it and how we want to build it in the future. The first version of this was released in November last year. This was mainly focusing on the PID and we have released the second version this year in March that focused even more on more details on the PID.

We include several options on this and also we include included the design of the electronic adaptation of attributes. In further versions, we will focus on more features like for example, QES for signing pseudonyms and operating models and many more. Consequently, the whole process always analyzes the impacts on security, privacy and the user experience. So this is an ongoing process and of course it takes into account the specifics of the German EID system. And in the following slides I will look into some of the specifics.

And the first emphasis of the architecture proposal was on the pit designs. Currently in the wallet architecture proposal, we analyze six different options on the PID, what they all have in common that we use the German EID card to identify and authenticate the user. And the question is then how do we envision the pit credential itself? And we have six different options in the first layer. They differentiate whether we want to issue them as sign credentials or authenticated channels. This is mostly motivated on the discussion whether we want repudiation or non-repudiation.

And the other question, the other differentiator is where we want to store our keys. All of these six different pit options will also be implemented and tested and the won funko wallet challenge that Torsten will talk about afterwards. And I will briefly go into these two questions that we have for the pit options. So first question is, how shall the cryptographic keys be stored in the Germany ideal wallet? IDAs and the A RF proposes the wallet security cryptographic device or insured WSCD. This is a temporary approved resilient key storage that also covers the user authentication.

There are different types of WS CDs and the choice of the WSCD has a major impact on your wallet architecture and your wallet design. In Germany, we envision three different options. The first one is to use the national EID card itself as A-W-S-C-D, thus has the advantages that we can leverage the high security of the physical cart. It's a notified EID system on LOA high, but it has the disadvantage that we have to tap the cart all the time. The second option is that we use an internal secure element in our smartphone.

This has the advantage that we have a fully decentralized system with offline capabilities. And the third option is to use an HSM and the cloud as a remote WSCD. This has advantages that we can reach a lot of, a lot of citizens. We're not dependent on features on the smartphone and this also enables easily backup and recovery mechanisms. We currently have a preliminary assessment of these different options under the, the view of security, privacy and user experience and scalability in the architecture proposal. So you can check out there.

The second question is on authenticated channels and sign credentials. As I said, this is motivated by repudiation, repudiation and non-repudiation means whether I can prove as a relying party that I received the presentation to somebody else or not. The way that many people envision verifiable credentials right now works as follows. We have the pit provider with his key in red and if he issues a pit credential to the wallet, this is signed by his private key. And this also includes the data of the PID itself. It also includes a blue device, public key here.

This is managed by the WSCD and if the wallet wants to make a pit presentation, it takes this signed pit from the pit provider and attaches a signature from its blue private key to this. And the relying party can now verify this by checking the blue signature and the red signature. But the thing is not only the relying party can do so, but anybody else can do so as well, whom the relying party is giving this. And this is where some people in Germany have privacy concerns because this is government signed data and they think it may be a bad idea.

So this motivated the idea for the authenticated channel. And I want to illustrate how this works because most people might not be so much aware of this. In this case, the pit provider does not authentic, does not sign the whole key. But he is only signing the blue public key from the wallet and issues the other pit at a station's first name, last name, birth date into the WCD itself.

If the wallet now wants to do a pit presentation, it first needs the green public key from the relying party and with the key from the relying party and the key from the wallet, they will make a key agreement and this will re result in the purple shared secret. And now the wallet is sending the pit attributes, the first name, last name, birth date with this purple key to the relying party. And the relying party can be sure that this is authentic because it can validate that the red signature, the key that the wallet used is actually authentic.

And it can also validate that itself has the purple key. So it knows that the put attributes are authentic, but the difference is that not only the wallet has the purple key, but also the relying party has the purple key. So the relying party cannot prove to anybody else that the data was authentic because they could assume that the relying party could change any data because it also has the same key as the wallet. And it works also similarly in a more easy mechanism.

If we use the EID card as A-W-S-C-D in this case, the key agreement is happening between the relying party and the pit provider. This results in this case in the brown shared secret key. And the pit provider is using this brown key to send a pit presentation to the wallet. And the wallet is just forwarding this pit presentation to the relying party.

Again, the relying party can be sure that this data is authentic because it has been done with the public key from the pit provider, but it cannot show it to anybody else. As a summary, we have signed credentials that are a well established mechanism and is very well understood and widely used, but it has non-repudiation. On the other hand, we have authentic authenticated channels. They also allow integrity and authenticity and it's, it is also a well understood mechanism. For example, it is one option in the iso mdoc format.

It enables repudiation, but it is less common and it may create some problems in the protocols. And as a third option, we are also thinking about using sign credentials in a reputable way by publishing keys. This is also a new mechanism that we're looking into.

Again, if you think non-repudiation or authenticated channels are a bad or a good idea, feel free to give us feedback in the issues of or open source architecture proposal. And with this I'll hand over to Torsten. Thank you very much. So these and other questions pose hard topics that we need to tackle. And there are others like how can we really build with today's technology a secure EID function that also fulfills the requirements for lower level of assurance high?

And how do we build wallets that are truly privacy, preserving, taken into account, un observability, un linkability, and data minimization while being user friendly and also having a reasonable reach in the market Because there is no point in building a system that only works for one person of the population, right? And since we know those are hard challenges, we started an innovation competition. And this innovation competition we can f we know, we know funker, that's a German word for spark, right?

And we set out a tender and said, well, teams that want to help us to explore that space and build prototypes for different options, how those problems can be solved, please make an application. We would like to work with you. So we have a funded track and a non-funded track. Obviously the funded track, the teams get paid and they have to publish whatever they do in open source under Apache two and in a non-funded track, they don't have to publish, but we don't pay them. So that's a simple, that's a simple deal. There's three stages with different groups of challenges.

First stage is pit designs, poll explained the different options that we have been considering. Second stage is everything around privacy and privacy of preserving maintenance, maintenance and presentation of electronic attribute attestations. And the third stage is around pseudonymous login, anti authorization of signing and payment transactions. So a lot of stuff, the teams will compete with each other. And at the end of each stage, two teams on each side will be Christina, how did you put it kicked out? Yeah. Okay. And John Bradley said they, he is here to to, to kick assses.

So you see this is a very, very competitive atmosphere. So yeah, which are for the do, let's have a look on the teams that that we selected for the competition. So we have an international jury with experts from civil society, a user experience angle, security, data privacy and so on. And they've selected the, the companies they can either see on the screen because we are running out of time. I won't go into the details, however, I can tell you all the pit options that Paul just explained. We will implement it.

We will see prototypes, even if the most complicated stuff that requires a Java card app outlet in a secure element or an EEO ICC, we will see all that. And based on that, we can make our up our mind how complex, how feasible it is and whether we would like to pursue that going forward. So the horizon of that initiative is to figure out what's possible in 2, 5, 10 years from now. It's not about what we can do today, it's also what we can do today. But it's also about what can we do tomorrow and the day after tomorrow because that helps us to develop a roadmap.

And last point, since we have to provide a wallet by end of 26 27, we will be starting development of a identification solution in summer, most likely based on a cloud based solution of those that Paul just said. And we hope we will have something we can share with you by the mid of next year. And with that and since the moderator is approaching, I'm done. Thank you very much for your attention.