 We live in a world where there are very few certification authorities. Most of them are banks, governments, big corporations, but we want that each of you, each of us can be a certification authority. That's the main goal of the Iron 3 project. We want to democratize the certification part, the claiming part. When we are doing a claim, not matter if it's done by a government or if it's done by your fake identity, when they are doing a claim cryptographically, this claim is exactly the same. It's a claim that can be proved tomorrow or any day in the future. Before going deep in what technically we were doing in Iron 3, I would like first to introduce three concepts. I want to introduce what we understand as an identity, what we understand as a claim and what we understand as a proof. Identity, I don't want to go deep. I don't want to enter in philosophical, philosophical definitions and all that. I will put you some examples. An identity can be a person, but can be a company, can be an organization, can be a DAO, can be a government, or if you want, even can be a think, can be a microphone, or can be a chair, or can be this room, half an identity or a bot. In our system, when we talk about identity, mainly we refer to identities as accounts. We represent identities by accounts. In general, they are going to be smart contracts. Okay, so the address of a smart contract is going to be our identifier of that identity. The next concept is about claim. Claim is an statement. If you want, I'm not writing a statement. Okay, so something that an identity is saying. Most of the times, these statements refer to other identities. For example, when a university is saying that this student made a degree, this is a statement. This is a claim that the university is doing over that student. But if you think a little bit, you will see that almost anything that we are saying can be not rights, can be converted as a claim. Examples, an invoice that's making a company, a like in a Facebook, can be an endorsement to somebody else. Or if you want, even a single message, a single email at the end is a claim that I'm doing. As you can see, there are claims that can be public, but there are also claims that can be private. Claims is something that we are just saying. Okay, and the next, and why we want to do claims. Why we want to not write claims? Mainly because we want to prove those claims sometime in the future. And here is these three actor parties. They have the claimer. This can't be the university that's doing the claim over a student. And then the student, when goes to for a job and is proving to the employee that he already had this degree. And because there is this relationship, this trueness between the employee and the university, this proof is valid for him. Okay, these proofs can be many kinds of proof. We will talk a little bit later, but can be on chain proof. If you want to prove to a smart contract of chain proof, when you want to prove peer to peer, public proof, when you want to prove to everybody, there are many kinds of proof. But the system at the end works about, we're talking about these kinds of proofs. In Iron 3, what are the our goals? What do we want? We want a system that first of all must be private by design and by default. Privacy is an important value of Iron 3. We want self-sovereign identity. We want to address the key management. We want to be accessible, usable. We want it to be scalable. And we also want to be universal, that is interoperable between the systems. Okay, let's go step by step. First, self-sovereign identity. What does it mean with that? That means that any of you can create as many identities as they want. And this should be, I would say, free. Creating an identity should be as easy as creating a normal account. It does not need to have any gas and ether or anything like that. And we say that self-sovereign because you full control that. And the same way that happened with when you hold the normal account in Bitcoin, you need this responsibility of keeping the keys. If you lose the keys in some way, you can lose the responsibility. The same way that in Bitcoin or Ethereum, if you lose the keys, you lose that. You lose that. So because this responsibility, we need to work a lot in the key management. Okay, and this here we share a lot of the problems that any wallet have. Here, as you can imagine, the key should be revocable, recoverable. We are thinking that we don't want the keys to go around that leave the devices. We are sharing a lot of the concepts. And we are fully aligned with, I don't know if you saw yesterday, the Alex Bander Sauer universal login. We work in that direction. One key per application. So the key management is an important part of this project. Accessibility. I think we want to create a system that goes mainstream, that everybody should be able to use it. So be easy for anybody to start working in the system. This is, for example, and I'm going to start entering a little bit technical in how we are doing. We are using this when you are creating an identity. Mainly what you are doing is creating this counterfactual, or this identity contract that you don't actually deploy when you are creating that identity. But once you create this contract that's not deployed yet, they already have an address. So this already have an address. So this identity is created already. So the people can start doing claims on that. And all that without the user having to do anything else, they're just running at random dice at some point and creating that identity. Scalability. And here is where we are going to go deep. We want a system where everybody can create as many identities as they want. But we want a system also that anybody can create as many claims as they want. And to scale that in a global basis so that there are millions of claims in the world, we need to apply some techniques that I'm going to describe next. To explain that, how we anchor the claims in the blockchain. What we are doing mainly is if I want to create many claims, I put all those claims in a database. I take this database, I construct the miracle tree of that database, and I just publish with a transaction the root of that miracle tree on chain. Every time that I have new claims, I have changes, I would change the root of the database on chain. As you can see, this scales very well for identities that makes a lot of claims. Example, a government. In a government there are many things that happen in a country. There is people that get born, people that die, people that get married, people that change their addresses. So the government, just with a single transaction per day, could update the full database. If you want, instead of one per day, one per hour, or one every five minutes. But this is quite cheap for the government just to keep millions of claims database. But what happens when an individual user, a normal user, just wants to do one, two, three, ten transactions per day? Should they do ten transactions, should they do ten transactions if they want to make just ten claims? And here is when we introduce the indirect claims. What's the indirect claims? Here we introduce a relay. So when a user wants to create a claim, let me for example say, okay, I like this picture, okay, this is a claim that I want to do. But instead of creating a transaction, abating my root of claims, what I do is I'm telling to our relayer, let's think for a moment that this is a trusted relayer. We'll see that, that's not necessarily. But if it's a trusted relayer, I'm telling to the relayer, hey, relayer, I want to say, I want to claim that I like this picture. So the relayer, what could say is say, oh, Jordy makes a claim that says Jordy is saying that he likes that picture. Okay, this would be an indirect claim. But instead of doing claim by claim, what I'm really asking to the relayer is just to update my root of claims. Hey, relayer, please update my root of claims. So the relayer, just take that root of claims and publish as a claim inside that. And you see this miracle tree that depends on the other, on the other miracle tree. Okay, but this system, as you can imagine, requires a truseness between the user and the relayer. So in order to solve that, what we are working is in a truseless relayer. So what's a trusted relayer? A truseless relayer is a relayer that cannot chip. So a relayer that I can tell to the relayer and the relayer cannot publish anything on chain. To ensure that the relayer, when the relayer is publishing that on chain, it's also, besides the root, it also adds a zero-knowledge proof that guarantees that this claim, or if you want all the claims that are updated in this change, follows a specific rules. So in this way, the user has the warranty that the relayer will not chip. What do we mean with that? Of course the relayer can stop working. Maybe we have, maybe, or maybe you don't get any proof from the relayer. Of course the users also can, always can change of relayer and maybe change another trusted relayer. But if you get a proof from the relayer, you know that this proof is valid. Valid means that if this proof says that you claim it something, you can be sure that this user claimed it something. Or the other way around. If the proof says that you didn't claim something, then you can be sure that the user didn't claim, didn't claim that. As I told you to use that, to work with that, we need to create this zero-knowledge proof. As you can imagine, if you want to scale that, we need to create this big constraints circuit to create as many claims for transactions. And this is where we are working later. We'll explain a little bit the update on the zero-knowledge proof status. And let's go to the privacy part, because here we are also using zero-knowledge proof. But this is just to prove things without revealing the full identity. Imagine, for example, that I want to enter to a nightclub. I want to prove that I'm 18 years old, but I don't want to tell to the entry people who am I, where I live, and all the information about that. So I can make a zero-knowledge proof that proof that I really hold the key that according to the government, I'm 18 years old, but without revealing anything else about my identity. The same thing happened, for example, with anonymous voting. If I, when I want to vote, when I want to vote, I don't want to reveal my identity. I want to vote. I need, but I need to ensure that I can vote. That I can vote, that I can, that I am, that somebody claim it, that I can participate in that voting. Okay, this can be used in, this can be used in, so this can be used for a voting system. Another example that implies, for example, a smart contract would be an ICO. Maybe an ICO requires that the people that participate in that ICO is authorized by a third party because some KYC, some legal stuff. I can create an ICO, a smart contract ICO, that accepts zero knowledge proof, that guarantees that the people that participate that, it's okay, it's in the list, it's not authorized person. But without revealing exactly what I, who am I, or even how much money I spend on that, on that, on that ICO. Another interesting things that we are doing is this concept of non-reusable proofs. What's a non-reusable proof? Imagine that I belongs to a political party. According to the political party, so the political party maybe makes a private claim on me that I belongs to a political party. I want to prove him that I am from that political party. But what happened if he just published this proof to everywhere in the world? Everybody would know that I am from that political party. A non-reusable proof is a proof that I can't send it to him and I have the warranty that if he published that, it will not prove nothing. Of course, he can always say that I'm from that political party and it's information that he knows, but he will not be able to prove. How we do that? Mainly is we are taking the proof I'm from that political party, okay, and I'm creating like another proof that says, okay, I'm proving to you that I am from that political party or I know your private key. Of course, I don't know his private key. So he's sure that I am from that political party. But what happened now when he published that to everywhere else? He's saying, this proof is saying, Jordy is from that political party or I know my private key. So because everybody knows that he knows a private key is obvious that he can generate as many proof of those faking even if I'm or I'm not from the political party. So this proof is not usable anymore. So here is more or less the technical details of what we are doing. Of course, identity systems like this are required in, if not all most of the applications in the space, there are many use cases from reputation systems, directory systems, simple sign-ons. Many, I would say that almost any application that you think that there is like a login password will require an identity system like that. What's the status of the project? Well, we have been working very hard for the last four, five months. So it's a very young project right now. But what we have achieved right now, we already have a fully functional wallet, wallet for identities where you can see, where you can generate your identities. You can start doing claims, checking the claims, proving the claims and so on. We have a relayer right now is still a trusted relayer. And we have been working also in the zero-knowledge technology. For the zero-knowledge technology, we just, we right now just created a couple of tools. One is a circuit compiler. It's a, well, it's just a language where you can create zero-knowledge circuits. And you can, and then we have another tool that's called Snark.js. It's just a simple JavaScript implementation of the Zika Snarks. Right now, currently, we are working hard in trying to scale the generation of Zika Snarks proof. We are working with different people in the community and so on. Mainly the idea is to try to, our goal right now is to create one billion constraints in 10 seconds. That's our goal. And we are working with different technologies. GPU, FPGAs and different technologies and seeing and trying to check which one is the best one for that. And that's my presentation. Here are some takeaways. Self-sovereign identity should be a scalable, previously by design. We have this wallet and this key management, early version. If any of you is interested in checking and having a demo here, there is a bunch of people with my shirt. They will be glad to explain it to you. And also, focusing on the standardization. Standardization is something that we have not talked very much, but yeah, we believe that the system should be very standardized. That's why we are just an association. It's an open source project and we want to work and contribute as much as we can to a world where everything is more or less standardized and the systems connects one each other. And that's my presentation. Thank you. We have a fair amount of time for questions if anyone has any. Yeah, I just came back from the Internet Identity Workshop in California and it was great. It seems like a lot of these conversations are happening around identity in the Internet right now. It's awesome. I was curious if IDent3 has a DID method to be compatible with the DID spec. Yeah, DID is just a standard for referring to the identities. Of course, it's absolutely compatible because even there are some specific standards for Ethereum-based kind identities. So, yes, I would say that the current standards are applyable. The main problem of the current standards is that all these zero-knowledge technology is not very much on their main and, you know, for example, it makes no sense at all to put a JSON parser inside the Zika Snark circuit. So, I would say that there are some modifications and some adoptions to those standards that we need to take in account in order to adapt to this new kind of identities. So, if we're application developers, what can we use now if we have a need for identity plugins? Yeah, we are building, I think it's quite ready, but we are building mainly an SDK where all these basic functions of creating an identity, creating a claim, proving a claim, all that should be embedded as a black box. So, we are working in this library, in this SDK, where applications will be able to build on that. Our goal, for example, or the wallet application is just a reference application. We are working very much in the protocol, in the standard, so that even if anybody wants to create an application, that whole site entities in that site, that should be perfectly possible. Hi, I have a question over here on the back. You mentioned the use of Zika Snarks to alleviate this sort of trusted relay or setup. Zika Snarks require the trusted setup. Is that a concern at this, or is there anything malicious you could do if there was an issue with the generation ceremony? Yeah, Zika Snarks, we all of us, this is a concern. This is the big critique. I would say that Zika Snarks are quite perfect, except for that, which is a huge issue. So, yeah, the trusted setup is a problem that you have once. We are thinking in, of course, something that we are start thinking and seeing some solutions on that. We have thinking, for example, in using, for example, some trusted hardware to do these ceremonies. Of course, there is this multi-party computations on that. We need to automate in some way or the other. But the nice thing of the trusted setup is that once you have done that, and if everybody believes in that ceremony, it's valid, then the system is good forever. So, yeah, we are just analyzing different options of that. And, yeah, that's one of the weak problems. There are also these new technologies, the Starks, for example, that we are also very interested in on that, that they don't require these trusted ceremonies. And, yeah, they are quite better, except that when you want to go on chain, no, they are huge. I think the minimum was, I don't know, the kilobytes of data and putting that on chain, at least right now is quite a problem. So that's why we are sticking a lot in the Snarks. But clearly, Starks is a technology that we are start looking at, and it's another zero-knowledge technologies that are coming from the research world. There was someone who had a question in the back who has a mic. No, it skipped. Oh, I thought you wanted it. Who got it? Hi. Maybe this is a longer answer, but I was actually unsure how when the receiver of the identity, he exposes the information, his private keys, you were saying if he publishes the identity that his private keys were exposed, or he were saying the sender of the identity, their private keys were exposed? No, the private keys are not exposed, and private keys should not even leave the device. So a private key is something that only you hold, and I would say that it's very important in any cryptographic system that private keys keep secret. The only thing that we are transferring from one side to the other mainly are proofs of if you want requests for proofs. Hey, please, prove me that you are 18 years old. Here comes the proof. Okay? So that's mainly what the data that's moving is about proofs. I want to mention something that's important. We have not talked about where all these miracle trees and all these data is stored, okay? The data, each user should be responsible for their data. So if I'm doing claims, all the claims that I'm doing with all the miracle notes, all the notes of the miracle tree, I should care about that data. I can store that data. Maybe there is some people that's comfortable in storing that in a Google Cloud. Maybe there are some governments that they have their own premises. Maybe there are solutions that people that want to store those data in an IPFS, in an encrypted way IPFS, and maybe using no cipher just to access that data. So there are many options about where the user keeps that data. But in a self-sovereign system, each user has to take care of his data. Of course, we can provide tools in order to have the users. But it's important that we understand that when you have a self-sovereign identity, you own your identity. And that means you own your data. Question. So as a developer, obviously, I'm very interested in what you're doing. I'm going to take a look at your library. I'm over here. Okay. I'm going to take a look at your GitHub libraries as well as your documentation. One thing just to help me when I start that journey is compared to what is being developed by U-Port in the Ethereum space or Sovereign or Hyperledger Indy on their own chain, how would I think about this effort and this technology in comparison to those? Yeah, well, we are different projects that maybe we have different views. We are all of us working together. We are connected one each other. And we are just working, I would say, more or less in the same direction. But even if there are different projects that are trying to do a little bit the same, at the end, the end users, the developers, the people will just be the... They will say which is the one most useful to them. So it's not nothing wrong. What do you mean by connected, though? Is there an interrupt layer that you're looking to do? Oh, no, no. It just connected me that I'm connected with most of the people that's developing and we are trying to, you know, for example, the Ethereum magicians and in different environments, there is to try to generate those standards and those standards that we are aligned on that and trying to get consensus in what are those protocols. Here the main problem here is that now the technology is not clear yet. So I would say first we need to develop the technology, develop some applications, see how the people is using that, how the system works and once the recent adoption of those technologies, we can start thinking very much in what are the best standards. If we define the standards prematurely, it's possible that maybe the standards would not be working and maybe we will have another de facto standards. So here the tempos are very important. I think it's important that there are many teams that are working in solutions like that or solutions similar to that and keep working and being aware of what all the other teams are doing, just being transparent and the nice thing of open source is that we don't have to hide anything, just talk and if there are better ideas. You know, as an example, Alex Bander-Sar is doing an incredible job in the login. We are just going in that direction. Maybe there is some security issue that we are not, but we don't see it clear. Okay, we will tell him, hey, what happened with this? And there will be a talk and there is a feedback, a limitation between the teams. And if we work that way, I'm sure that we can get a good, we can get a good consensus of that. And if we don't get a consensus, maybe it's because there is two approaches that make sense. And at the end, the people, the market, the community will decide which one is the best one. Last question. Hi, Jordy. Thank you for your work. Really appreciate it. Right here. Hi. I was hoping you indulge us a little more. I'm very curious about how you made it a one-time use proof with a private key. Could you reiterate that one more time? The one-time proof, the proof that not reusable proof, you mean? Yeah. Okay, the idea is, imagine that I want to prove that I am from a specific religion. I don't want you, just you understand that I don't want you that you are able to prove to everybody else that I am from that religion. But actually, I want to prove you. Okay? So the proof that I'm sending to you is a proof, so I am proving to you that I either I am from that religion or either I hold or I have your private key, which I don't. Okay? So I will be able to create a valid proof if I have your private key or I am from that religion. Because I don't have your private key, the only way to generate a proof of that kind is by really having the claim that says that I am from that religion. Okay? So when I send you that proof, you have the warranty that I am from that religion because I don't hold your private key. What happened when you take that proof outside, when you publish that proof? You are saying to the people, world, Jordi is either from that religion or I hold my private key. So everybody knows that you hold your private key. So this, you can generate as many proofs even as you want if I'm from that religion or not. So this proof to the people is not valid anymore. It's not a valid proof. Other thing is that you can do a claim saying Jordi is from that religion but then it's according to you that I am from that religion. Not according to the church that I am from that religion. That's the difference. Of course when I'm proving something to you I'm giving some piece of information but I'm giving to you. I'm not giving a proof. So what I'm not giving is the capacity to prove that that information is valid. Okay? I think that's very tricky. Here I have to thank you a lot here to Vitalik because the idea comes from him in some sense but I think it's a cool idea.