 born in Germany, and living in the Netherlands already since 2006, currently living in Nijmegen, working for Radbord University. And, yeah, as already mentioned, I want to tell you about Jima and the very fabric credentials and the subtitle, how to authenticate in a decentralized privacy friendly in a more reliable manner across systems. So, first, I want to talk about one of the current issues with identity management. That is, it's centralized traditionally. So, I give one example, this is one model, but there are other models, but for now, let's keep it simple. And, yeah, this is me. I want to authenticate or request the service at my Health Insurer VGZ, which is the service provider in this case, and so I'm requesting a service and in order to be able to access the service, I need to authenticate, and how does this work in the Netherlands? Usually, the service provider asks DGD, which is the identity provider, one of the identity providers in the Netherlands owned by the government to authenticate to certain services. And so, the service provider asks DGD, is this really Daniel? And then I need to authenticate at DGD, and DGD then gives it OK to the service provider that I'm indeed Daniel. So, in case of extreme events, we clearly see that this sample party, the identity provider DGD, is one of the bottlenecks. Because we have seen in the past that there were denial of service, attacks also on DGD, and it was not available for some time, and also quality of service issues. So, researchers and industry are working on solutions worldwide. One of them is IEMR, standing for I Reveal My Attributes, developed at Rapport University some years ago, and it advertises itself on their website with having the digital passport on your phone. Currently, it's maintained by SCDN, which is also responsible for maintaining the NL domain. And one of the interesting things about IEMR is that it's completely open source, so you can look up all the source code on GitHub. And it implements partly the IBM's idemix specification. That idemix stands for identity mixer, and it's a cryptographic protocol suite for privacy-preserving authentication. If you want to learn more about the implementation of idemix within IEMR, then I invite you to go to the talk in the evening of Maya and Zitze, also sitting here, which will tell you at 9 p.m. today in the uppercase about IEMR's idemix implementation, the crypto-behind, selective, unnegatable attribute disclosure. So, how does IEMR then work, and also similar systems? We have two independent processes. First, the issuance, and second, the disclosure. First, doing issuance. For instance, the government in the Netherlands can issue me a personal data credential, which consists of my name, my birth date, and, for instance, also my address. So, this credential will then authenticate to the government with DGD, will be transferred to my phone, and me, as the owner of the credential, then, yeah, can disclose this credential to whenever I want. A credential consists of certain properties. So, first, it's bound to the phone via some cryptographic tricks, and it contains metadata from which issuer is issued, for instance, the Dutch government, also when it was issued and when the credential expires. Also, logically, it contains then attributes, and, most importantly, also the issuer's signature, because the issuer signs all attributes, such as another party, the verifier, can verify that the credential and the containing attributes are indeed valid and issued by that issuer. So, if I now want to use those credentials, I can go to a service provider, and the service provider requests, then, that I need to prove something, for instance, that I'm above 18 years old. So, where do I need to want to disclose such information, for instance, when I want to buy some liquor at the Chalenghal? So, the Chalenghal is, in this case, a service provider, and he wants to know that I'm indeed above 18 years old. So, the trust model, in this case, is that the Chalenghal trusts the government that the government issues valid credentials to the rightful citizen. However, during disclosure, the Chalenghal does not need to talk with the government. So, this is privacy-preserving, in that sense that the government doesn't learn as identity provider when I use the credential in question. So, that's one of the advantages of this decentralized identity model. So, zooming a bit in, how does a session in IMA work? First, we go to a website, and I chose now to have an example of Verifier. The Verifier then starts a session at an IMA server, which Verifier can run himself. After initiating the session at the IMA server, the IMA server returns some session information, and based on the session information, the Verifier can create and show a QR code to the user. Then, the user scans the QR code, so the IMA app gets information about the session, and subsequently, the IMA app also requests the information which attributes need to be disclosed. And then the user can choose, with an IMA it's possible to also make a construction that the user has a choice, which attributes to disclose, and then he can select in the app and disclose the attributes, and then in the end, the Verifier can look up at the IMA server if the disclosure was indeed successful and valid. Now, one practical use case I want to refer to, because I'm currently working on it, is Postcard. In Postcard, we have the goal to make email encryption accessible for everybody, so it's easy to use. Yeah, we all know the usability issues with open PGP, right? And how we do that is by utilizing identity-based or attribute-based encryption. In this concept, we have a private key generator, which is a trusted third party, so that's also an issue, we'll talk about it in a second. And if Alice wants to encrypt for her doctor Bob, for instance, she just needs the identity of Bob, for instance, his email address and some attribute related to that he is a doctor, and the public key of the public key generator, and then Alice can encrypt the mail. Then we ship the mail via our well-known SMTP protocol to Bob, but all the payload is encrypted during transport, and Bob can then decrypt by proving his identity via EMA to the private key generator, and if the private key generator then validates the disclosure, it generates a user-secret key that matches the identity with which Alice encrypted, and then Bob can decrypt the email. So this decentralized and user-centric identity systems are also referred to nowadays more often as self-sowing identity systems. Christopher Allen published an article in 2016 titled The Path to Self-Sowing Identity, where he also lists 10 different principles such a system should adhere to. Unfortunately, it's also often associated with distributed ledger technology, because the bigger parties such as IBM really used it for marketing purposes to sell their distributed ledger technology more. More recently, in Germany, there were some projects called IDWallet and the digital school certificates based on distributed ledger technologies and the principles of self-sowing identity, as we've seen those projects failed at the moment, so they're not online anymore, and I think they will further work on it, but also the Bundeszentrale Versicherheit in Informations Technologie, the BSI, discourages the use of distributed ledger technologies in such decentralized user-centric identity systems. Also interestingly, recently, the European Union announced that there's a European Digital Identity Initiative. There's still a call for proposals. The deadline is on the 17th of August, 2022, and they asked for the industry and researchers to submit solutions per country and with the goal to have per country maybe one system deployed in the end and that those systems are then interoperable, so if I now travel with my credentials to Germany that I can also use my Dutch credentials in Germany to authenticate and, for example, to prove that I'm above 18 years old. Also, Jima is also participating in this. So there is also some discussion, especially in Germany, that there are also some drawbacks with self-serve identity or decentralized and user-centric identity systems in general. Some of those arguments are nicely written down by Lilith Wettmann. My German friend here will probably hear about her in the last two years. And she argues that with self-serve identity systems, service providers have verified data stored and those are more valuable for criminals. Also, once you have such an infrastructure deployed, it's also easier to add identification obligations in the future. Also, states often leave it to the market to develop solutions. And then the question is, what's the business model then for those organizations? How do they want to earn money with their identity? How do we want that as a society? And, yeah, citizens are then becoming responsible for maintaining their credentials within their phone. So what happens if someone commits fraud with them? Who is liable for this? One of the goals of the European digital identity was to make such platforms interoperable, right? What I said, so you can travel from Germany to the Netherlands and then use the credential from one country and another country. So one of the current issues is that there is no standard defined how different identity apps such as EMA, ITSME, Schluss or the American sovereign talk to each other, right? How to exchange credentials between systems, such that I can, for instance, have my personal data credential from EMAs stored within my EMA app, and someone deploys an ITSME server and then can verify my EMA credentials within an ITSME system. First, W3C, the World Wide Web Consortium, developed a standard called very valuable credentials, data model. And it became a recommendation, version 1.0 in May 2020, I think. And in the meantime, they also updated some minor things. So it became a 1.1 version. So important to see here is that this proposal contains a data model which is an unambiguous specification defining the interaction between worlds and related concepts and also providing a syntax, usually in JSON, so I will give a little example in a bit. So if we now look at the walls and information flow of the very valuable credentials data model, we see clearly some similarities with the EMA system, right? We have here an issuer that issues credentials. We have a holder or a user that needs to store the credentials within a wallet app on the phone. Then we have a verifier on the right end that requests credentials and verifies them. And on the bottom we see we have a very valuable data registry that maintains identifiers and schemes. So I didn't talk about this yet, but I will do in a bit. And with an EMA, yeah, we have the similar concepts. So an EMA scheme is very important because it contains information about the issuer, which credentials an issuer may issue, and also the public keys of the issuer that a verifier needs to be able to verify that the credentials are indeed valid. So the EMA scheme is distributed via the EMA scheme manager. So it's hosted on GitHub, and every instance of an EMA service or the EMA app regularly pulls the most recent version of the official EMA scheme. So it stays up to date. However, in the very far credential data model, the, yes, it works a bit differently. So for instance, as you can see here, the green row within this except example, we see a URL that links to, yeah, if dereferenced contains some information about the issuer, and I think most importantly contains the public key of the issuer, so anyone receiving this credential can verify it. So what I did within my work is developing a metadata server within the EMA system, such that external parties can request information about the issuer and about the credentials used by offering two distinct endpoints, the issuer and the schema endpoint. Yeah, so we can conform to the verifiable credential data model. So the prototype I built to summarize is providing this metadata server, a wrapper within EMA Go. EMA Go is a central component with which you can run an EMA server, but also parts are used within the app to compute verifiable credential compliant messages. Also, I showed that we can exchange verifiable credential compliant messages between different EMA components. So during my study, I was not able due to time constraints to find other parties, for instance, it's me or Sovian that want to work together with me to show that we can indeed exchange information between different systems. So the source code is also available on my GitHub. I forked the EMA Go and the EMA mobile repositories and to wrap it up, I think. How's the time? So what I just said, the prototype shows how to compute VC compliant messages within EMA. By conforming to the verifiable credential data model, EMA's interoperability increases. However, one of the most important things to discuss still is that the APIs and the cryptos a system implements can differ in each system and that's also the biggest challenge. For instance, EMA utilizes the IBM's IDMICS specification to implement some protocols, but other systems can implement other cryptos. So how do you make sure each system understands crypto of all the other systems? I think that's one of the most complicated things in this whole verifiable credential standard. I think we have a similar discussion currently about making messenger apps interoperable. I think there we have kind of the similar challenges. So on a more higher level, we can state that with decentralized identity management platforms, we can improve the reliability during extreme events because we are not relying on a central identity provider. There are also several decentralized and user-centric products available on the market. As you see in EMA, for instance, in Schluss in the Netherlands, and it's me in Belgium, which is really used heavily there by citizens. The BSI states that it doesn't recommend the use of distributed ledger technology within such systems. We have seen that systems use it for storing also a scheme. So in a decentralized manner, they try to distribute the scheme such that everybody can receive the right information about issuers, for instance, the public keys. And in the end, we have the European Digital Identity Initiative. It gives opportunities to empower citizens to be in control, in sole control of their identity. But as I have shown, there are also some drawbacks that we still need to address. So it's a call to action for everybody here who wants that this goes in the right direction because within the European Union, there was also one point was that we have some unique identifier for every citizen within Europe so that we can identify everyone, and I think we don't want that as a community here at least. And yeah, that's the end of my talk. And so we still have some time for a Q&A. So thank you very much. And if there are any questions, please line up at the microphones in the middle of the room. We do have some time if anyone wants to know anything. Okay. First, front microphone, please. Hi, you mentioned and it's on the slide that a distributed ledger is not recommended by the BSI. Could you tell a little bit more about that, about the WISE? The WISE? Yeah, because they argue that the technology is not major enough and it gives more risks than it benefits an actual system. So I don't have all the details now in mind, but I referenced it. So yeah, I asked you then to look up if you really want to know all the details about what they write in their report. So yeah, that's... Okay, next question. Hello, thank you for your talk. Let's assume that everyone, every wallet now has those verifiable potentials. We don't have interoperability yet. What would you recommend? How should the wallets then work together? If we don't have interoperability, you mean? Let's assume we all implemented this and it's just a standard and you know there are still limits. You don't have the interoperability just by implementing the standard. So what if we now have all those verifiable credentials? How should we continue to actually get interoperability? Yeah, exactly. So to increase interoperability even further. So I think what we need is some agreement within the community also to think about which kind of crypto we want to support. What is really the good crypto for instance, right? What Yemma currently implements parts of the identity mixer of IBM that we kind of standardize this and make it kind of a library so other systems can just load this library and then have the crypto included in the system already. So I think it needs to go into that direction that we have some agreement on the good crypto and then maybe have different libraries that implement this different cryptographic systems. So other decentralized systems can easily implement it or use it, let's say. Right. Okay, next one. Hello. I would like to remind you that we had a talk about bringing your own identity on Friday which allowed authentication on any server by using one identity provider and maybe after this talk we can have a little chat how your Yemma project can coincide which might help us bring your own identity project and the designer of bringing your own identity will be here in a while and maybe that's interesting because what we did we created a system to prevent to have credentials on all those servers such as Google Facebook and so on to be removed and be delegated to your own identity provider because this talk is also very much about identity maybe they're interesting questions so to speak it's not really a question but maybe I want to point out maybe something can be combined with Yemma and bring your own identity but if I understand correctly you say that you then have different your identity stored at one identity provider but then it's also centralized in a way, right? So that's also a risk. It's also a problem but because when the identity provider goes down you can't identify anymore but that's what you solved maybe that can be combined maybe we can talk later also so apologies if I missed most of your talk so I was paying attention to these verifiable claims work attached to the W3C from pretty early because I had somebody drag me involved in the payments thing there was a lot of incompetence there from the beginning but one of the things that stuck out to me and apologies again if you've already touched on this but you really don't want any identity system that is sort of general purpose and relocatable against different things and that reveals attributes of people so if you go through the verifiable claims their documents their use cases documents it talks about using to prove you have a job to get a bank account which okay that's fine but how often do you open a bank account it's perfectly fine to ask your employer for a letter whereas what's much more likely where that feature would get used much more often would be when you're going to apply for a job because an HR person generally prefers people to already have jobs and so they'll just filter everybody because that's how bureaucracy sometimes work and if you go through all of their use cases you can pretty much just flip it on and say how can this be misused and pretty much all of the attribute use cases can be misused so my general feeling so the question part of this is have you looked at Brian Ford's proof of personhood parties because in Brian Ford's model there are no attributes that's just you have it's a function that maps a context to unique identity and so then we need for then we have no attributes we just have in a given context I have a unique identity and then I have another one and another identity and there's no so you mean you get the identity from the government for instance right which has some unique identifier in his model so he has this anarchist thing essentially they want these proof of personhood parties where people produce but de facto the proof of personhood parties are a side government so yes it's coming from a government but it's not the government it's this like anarchist construct but you could do it issued by a government too so yeah I don't really understand it correctly yet like yeah maybe it's not after yeah end time is up sorry but he will be available afterwards I'm sure and thank you very much for the talk I think you were the first person who tripled the audience during talking so please give him a round of applause it was just at least tripled two before