My name is Andreas Freitag. I'm the co-CEO of Procivis. We have been working in the digital identity technology for the last three years and working on our technology solution. I have the honor to have more time than predicted. So we have more time for the topics because there are a lot. What we are doing or we are focusing is how you can implement eIDAS2 from a government perspective in the first step because governments need to implement the infrastructure and then the private sector will follow.
But there are a lot of things what keeps us up at night and I'm sure a lot of authorities and governments have the same sleepless nights. Short disclaimer, each point of this agenda is worth a week of workshops. So I'm really covering them high level. We can discuss afterwards if you want. From a government viewpoint, we are facing several centimeters of regulations at the moment. So I don't know not everything which is written in the eIDAS2 regulation, implementation acts and other referred standards. Next thing is the regulation leaves room for interpretation.
It's like a cooking receipt and if you give the receipt to five different cooks, you will receive five different meals which maybe are the same but will taste and look different. And that's one issue for the regulation. And I will focus on technology, not on regulatory and it's also no legal advice. Everything what I'm saying, please, it's no legal advice from my side because I'm not a lawyer. What are these topics? So first one, we go from easy to hard. The basic setup, you will see what I mean. You have to decide for a basic setup if you implement the eIDAS2.
Level of insurance high is a big topic and it's a it depends topic. Trust management and wallet unit at the station have a question mark because they are totally open at the moment from the technology perspective. The timeline we have and then we have interoperability as the hardest at the end. So who is Procevis? As Daniel said, Procevis is the subsidiary of Aurel Füssli. Aurel Füssli is printing the banknotes in Switzerland and the passport. It's a 500-year-old company and with Procevis, we are going to the digital market and it's a digital pillar of Aurel Füssli.
What's the background of my presentation? So we are literally implementing this stuff since three years. So we know the pain of it and you can also test out our technology. We have our core product. It's available on GitHub. It's open source because it has to be open source because of eIDAS. We have a mobile verifier and a mobile wallet on the app stores you can download and we have a trial environment where you can apply for free. You can also try this out. What is the basic setup?
The basic setup is there are a lot of possible flavors and standards you can pick based on the current eIDAS regulation. First, wallet key storage. You can say I'm fine with secure element on the phone. You can say I'm fine, I need a remote secure element like provided from Boris who has the talk afterwards. So first decision, make your choice as a government authority. Credential format. At the moment, you can pick the ISO format or you can pick one based on W3C VCDM. ETF is not in the standard at the moment but most probably it will also come in the standard.
Here are your first choices and then revocation mode method, also different choices. But that are the easy choices you have to make as an implementer because that's pretty clear. Here you see our solution, the architecture picture. All these boxes are available. Make your choice. Next one is level of assurance. Level of insurance is not in the eIDAS regulation. It's a separate regulation. Level of insurance means how much I can trust this identification means, this thing. There you have low, substantial, and high. The eIDAS say it must be high. So you have different options.
The thing is there is no single solution. You have different process steps described in this regulation. This is the enrollment, so how you onboard your citizens to the bid to eIDAS tool. It's how you use it, the management, and how you store it, the storage of the stuff. This is how you can use it. You have in this regulation different chapters and you have to fulfill all with level of insurance high, not just one. If you have achieved on a certain step only low, then everything is low. I picked just two examples that you see. You have to make choices also.
You have to go to your lawyer and see what's your local regulation and so on. What's your interpretation of level of insurance high? That's the enrollment process. You can always go to the office and say, here I am. I'm picking up your physical passport and enroll. That would fulfill level of insurance high because you are sitting in front of the officer. Second one is you can base your enrollment on existing apps which have level of insurance high or substantial. But for high, you need a second factor, a PIN, a letter, a request, something in addition.
The third one is integration with existing apps. You just have to check the validity of the app again. That also depends on your situation. The Nordics have bank ID, but bank ID is just level of insurance substantial, I think. They have to challenge how they can raise this level when onboarding on the IDUS2 with an installed base of million users. Next one is storing. How you store your credential. With substantial, you just need a holder binding and a second factor. I would say you can also use software keys that enables you that you can backup and sync your credential.
But it's not level of insurance high. With high, you need a device binding. That means this credential must be bound to your device. This can be done with the trusted secure element on the phone. But if your regulations say that's not enough, you maybe need a remote secure element. Here again Boris. These decisions you have to make as an implementer. That can cause, of course, sleepless nights. Now we come in the realm of that's not specified yet. Trust management. What means trust management? IDUS2 says every relying party and provider has to be registered. That you can check as a holder.
Is this verifier issue legit or it's not legit? It's like your SSL certificate on your browser. Is it green or red? Here we have trust management in our solution. Just that you can see it. You have the list from the onboarded verifier. In the wallet you see that's the police of Bavaria. I can trust them. I can share the data. But how you implement it on a technical level? You can use credential-based revocation. So trust management with the credential. You can use classically X509 certificates. And with revocation checking with CLRs or CSPs. Or you can use just a simple list with an API.
It's not that privacy preserving but also possible. The standard, at least I haven't seen it, defines not the technical solution. It just says it has to be trust management. And it has to be interoperable in 2027 with other countries. So that makes things really hard. Also for us because we don't know. We cannot implement every option. We need also from the technology side as a provider. Some kind of certain direction what we should implement. Next one is wallet unit attestation. Wallet unit attestation for you. You don't know what is a wallet unit attestation.
Each wallet when you install it needs an attestation for this wallet. And this attestation must be possible to revoke it. And to more or less shut down the wallet. In case your phone is stolen or in any other case. And also here with this wallet unit attestation. You can do it again credential and certificate based. Like you get a wallet unit attestation as a certification. You provide it to the verifier. The verifier checks this like a credential or something else. Check if it's revoked. Fine. One option. Another option is again list based. You have a list. You are entered in the list.
The verifier can check is this wallet on the list. Has it a valid attestation or not. Here also you can implement a system where you download the whole list. That's pretty privacy preserving. You can implement an API. Whatever. But it's open at the moment. So also the implementation acts don't say in which direction we're going. There are some more details in the architectural reference framework. But the reference framework is not law. So a country can do it as they want if they fulfill the regulation. Timeline. Happy new year 2027.
Because at the moment the regulation says the deadline is at the end of 2026. And that's pretty close when you look at this timeline for such a project. We have still implementing acts are not enforced. So one is planned. I think there is a meeting today in Brussels. And there is the third batch I think is in review. So at the end of this year we have all implementing act when it's going to the timeline. And then we only have one year to implement. Everybody who has implemented systems in this scale knows that's really a crazy timeline. And in 2027 the private sector must accept it.
And also it must be interoperable. What I hear often is the technology is easy. A lot of countries are now discussing about certification schemes. Who is responsible for it? And the assumption is the technology is easy. Everything is available. We do it in some months. I doubt that with the experience from our last three years. So our approach to hit the timeline is we go in pre-production projects now with our customer. And we are covering the technology and the regulation and the processes in parallel. Because if you figure out a regulation with fitting your country and your requirements.
You also have to ensure that it's technically possible. So these things have to go hand in hand. And now is enough time to do it. And we are not speaking anymore from BOCs. We are speaking from pre-production projects. Because that are the base for the next step for set it into production. We are not throwing away anything. And if you start early enough, you have it 2027 in production.
And yes, we have time. Because my speaker before gave me some more time. And interoperability is also a big topic. Everybody is talking about we are using the same standards. It's so easy.
Spoiler, it's not. Because the standardizations also if OpenID is in June in version 1, it's a receipt for a meal. And everybody can take this option, take this option. Use the metadata in this way. So we never experienced interoperability testing with another implementation which is working out of the box. It's really hard work to get it running with the U-reference implementation, with the Swiss sandbox. Because every implementation is different. Everybody is using the same standards, of course. But the standard is not an implementation. And this picture, the Tower of Babel shows it.
There are a lot of languages you have to speak to be interoperable. So what's your guess? How many flavors we see in Europe of the EIDOS2 implementations? 27. Thank you. At least. Some countries cannot agree internally. Yeah. We'll see at least 27. I haven't found two countries working together. Everybody is doing the same. Everybody has clever people doing implementation. Everybody has legacy. So there are reasons for that, yeah, that they're doing it on their own. So no implementation or wallet or verifier issue will be interoperable with other countries out of the box.
So that's my prediction. Will not happen. So how we can come to interoperability. So now we understand the problem. We tried with languages with Esperanto. We failed. We're not speaking the same language. We now agreed on bad English that we can communicate. But we have to learn it, yeah. So I'm also assuming there will not be one technology provider everybody is using. But here is one. If the countries want. So it can be easy. That would be like everybody is using Microsoft Teams and Word.
And yes, of course, it's working together. But if somebody is using LibreOffice or OpenOffice, things get really messy. So you have to manage this diversity. And what we are doing, we are creating a kind of bubble fish at the moment. It's a huge work in front of us. I think CTO Sven is also in the audience. And I think he's got goosebumps and sleepless nights. We are creating country profiles. As soon as a country profile is available, like in Switzerland, the sandbox or the reference implementation, we create this country profiles, which you can pick and choose as a customer. Really easy.
Our design of our architecture, as you see before, is with flexibility in mind from day one. So we can easily mix and match things, create own profiles and so on. So we will create this bubble fish. And solve this interoperability issue with flexibility. We have also done some projects in this direction. We have done a project with DHS last year where we had exactly this challenge. The Swiss standard and the standard specification from Department of Homeland Security. What we have done here is a Swiss woman is going to America for study, gets a permanent resident card.
And gets checked at the employer or also on the border crossing in Canada. Because her green card is bound to her Swiss eID. Totally different formats for the user. He doesn't see any difference. It's the same. But in the backend you have different formats, different standards. Another one where we are ahead is the city of Zug that's in production. They are using our solution to have DJ IDs as a first step. And you get a discount at the local store with this ID. And here we have chosen a stack which is close to the Swiss stack. But it is not the Swiss stack.
But it's easy for us to change it in the background when the Swiss stack is then in production. So the user will not see anything or feel anything. It's just the update of the app. And then he gets the credential with another format. Who are we? We are based in Switzerland and Austria. Some colleagues are with us. So Patrick is here at the conference, Sven and me. So if you have questions or want to discuss some topics in more detail, please reach out. Are there any questions? You should see a QR code again if you want to submit your questions online. That's also possible. We have enough time.
Yes, enough time. Who read Hitchhiker's Guide Through the Galaxy? Anyone wanted to understand how a Babelfish works? Here is the guy who has the answer. You focus on technical interoperability here. Then we have the other level. That's the governance, which is interoperability between the different member states on how those different lists are issued and governed. Any clue on what was your suggestion or estimate on the timeframes related to that? Will they make it to the deadline of end of next year? I think that we will not see all 27 countries in production end of next year.
Because then you have to start already or you have to work on the implementation. And the interoperability and the merging of the trust list is then one year later. And it will be also a little bit later. But just my opinion. But at the moment we are working with the deadlines in the regulation. I have a question about relying party. Do they have to all be trusted? So only the ones that are registered can use the wallet? Now only the ones that are registered can verify credentials. And also providers have to be registered. So there will be no unknown party in this ecosystem.
I was thinking of like age assurance going to a bar. If I want to show my ID. The bar must register as a relying party. And it's totally unclear. I think also the colleagues from Sprint said that how this registration will work. I hope this registration will be easy and fast and without pain. With two minutes on a website. If it's a two-week process you pay 1,000 euros. And you have to bring five certificates. You will not get an adoption. So the bar is then registered and say I'm a bar. I want to check the age and only the age. And that gets in the trust list.
If the bar checks more than the age then they get an issue. Because it's in the trust list. Who you are, why you want to check, what you want to check. And you don't have a privacy issue because the bar only checks your age. And nobody knows that you are in the bar. Because it's a decentralized system. Thank you. So this is kind of a personal question. Because I actually used to live in Switzerland. And I'm very interested in how Switzerland is going to work with the EIDES. Because I know that Liechtenstein, which is not part of the European Union. But part of the EEA is in the EIDES system.
So Switzerland is neither of the EU or neither of the EEA. Won't be in part of the EIDES ecosystem. And as the gentleman there have asked, legally speaking, I suppose that the Swiss companies, which is registered only in Switzerland, won't be able to become neither verifier nor issuer.
But still, there would be many cross-borders between Switzerland and the European Union, Liechtenstein and other European countries. And what are any strategies for Switzerland or the European Union side? I can only quote the colleagues from the BIT and from the Ministry of Justice in Switzerland. At the moment, they're implementing their own stack. But the goal is to be interoperable with the EIDES 2. That's the technical level. And that's on the roadmap, but after the implementation. But then you have the political and legal level.
And if the government from Switzerland don't come to agreement with the European Union, it will not work. So I think there are two levels which you have to solve. The technical and the political. What is more easy, I think, is the technical. Thank you. And I guess the Swiss people do the vote for everything. So I wonder how Swiss people would… Sorry? Because Switzerland, they do… The Swiss citizens vote for everything.
You know, the national vote. Voting for all kinds of legislation. So I'm wondering how Swiss… Yeah, there will be voting in September now, I think. The news broke today. It's confirmed there will be a referendum in September.
Yeah, that's the word. Where the citizen can vote against or for the Swiss EID.
Oh, great. Thank you. Thank you. Any other question? I'm sorry if this question is answered in your paper. But you said that you have a production ready or a use case in production. Does that use any of the EIDES trust lists or any of those… Yes, of course. …mechanisms?
Yes, of course. I think Sven is here. Are we using ETF estate shot or W3C? ETF or W3C?
So, I mean, to answer the question, right, the trust lists from the EU are not in use, obviously, in Switzerland. It's a Swiss commune, Swiss city that does it. So we cannot, obviously, integrate with the trust lists of the EU. But the rest of the technical stack is the same, right? As Andreas mentioned, ST shot, W3C plus… Yeah. The thing is, our solution is our solution. So there's everything in. You pick what you want. You have everything in the core. So we're not delivering just this stack. It's really everything is in the stack.
So, yes, as far as you can fulfill the EIDES 2. Yes, we say we are EIDES 2 compliant. But as I mentioned in my presentation, there are so many question marks. We would love to have less question marks because then we can develop with more certainty. But what is certain and what is decided, we have developed and we can provide.
Andreas, thank you very much for this.
