Remi Colin I Verify Identities Onchain Using Self SDK I ETHGlobal Cannes 2025

[Music] JM and welcome to this self workshop. So today we are going to see how you can using self generate zik proofs about your identity like um the fact that you're 18 plus the fact that your parts are not part of a specific countries and each time without to having to reveal anything else and the best is that you can verify these proofs because these are zika proofs you can verify them onchain or offchain and the implementation is actually extremely simple. Um we have a bunch of SDKs that are available. So we are going to see all of this together. All right.

But first the plan about today is uh pretty simple. So in the first time I would like to give a bit more context about the protocol. Then we can chat about the bonies because maybe you are here because you are sponsoring the global. And finally, I think that the best is to get our hands dirty and just learn by doing and yeah, good with examples. So let's say that you're an application that needs to refer the identity of your users and you need to do this onchain or just online, you know.

So currently the fallback solution is the well-known and overused KYC process which is pretty bad for many reasons. Uh first it's not private meanings that you're going to share all your information with the third party application. It's also not really secure. Um now using generative AI it's extremely simple to pass this process. And last time I think it was two weeks ago I saw something like for 15 bucks on the dark web you can pay to pass this process.

So even from the application perspective it's it's definitely not secure. And finally the user experience is pretty bad. Um each time user will have to find the documents scan it send for verification and then wait until the verification occurs. So um if you're an application you are going to experience a lot of drop off here alternative to the KC um by building a decentralized identity but to this day it's um it's quite hard to find something that is um really convincing. Uh the general proof of personhood used to be quite popular before like proof of humanity in which you you hold a sheet of paper in front of your camera with your address written on it.

Um an idea you use to soft captures to prove that you're real human. But um unfortunately we could expect um but unfortunately we could expect but unfortunately we could expect uh within few years AI to be able to self captures the human concept. Then you have the biometric proof of personhood. So these one are super interesting because they are private like W for example. But some people can be reluctant to scan their eyeball obviously and because um it's hardware based solution it has the drawbacks of hardware meaning that uh you could put a bar inside or you could also trick somehow the sensors.

Uh finally you have all the social graphs based solution that are cool because they're fully decentralized but unfortunately still gameable. So that's why a few years ago we decided to build self um by leveraging the most trusted attestation of who you are aka the biometric passport. So uh the paradigm itself is quite different. Instead of building everything from scratch, the idea is all right, let's just piggy back on the existing ID infrastructure structures that are um in the wides and let's hijack them using ZK. So biometric passports are pretty good fit for that because they are quite hard to obtain and unique to individuals.

Most of the time people only own one passport. Maybe you maybe you have to because you have a dual dual citizenship, but it's still quite scarce and yeah, if that's the case for you, you're extremely lucky. Also, they are pretty secure um in a way that people have this inition that um a passport is something pretty uh that you should take care of. And finally and most of all they are machine readable meaning that um using the camera you can scan the machine readable zone of the passport for example on the main page but there is also in biometric passport a chip that you can read using the NFC reader of the phone and this chip contains most of the passport data but also um the digital signature of the document meaning that you can verify this digital signature inside the zero knowledge proof. And by doing so, you can already mitigate most of the issues related to to identity, such as prove that you're real human.

I'm a real human because I own a biometric passport, a biometric ID, something like that. Um, you can also prove random stuff about you like the fact that you're 18 plus, um, the fact that you are not part of the offction list. And so here is the list of what you can already prove using self. So you can prove that you are part of a specific country, that you are not part of a country list, which is pretty good for compliance. You can prove that you're above a certain age, that you're 18 plus, uh that you are not part of the offaxion list.

You can reveal stuff about you. You can reveal your name. You can reveal your birth dates. you can reveal um unfortunately not your hair color but soon you will be able to do so because it's inside the picture of course um you can and you can associate all these information that are attached that are part of the proof actually with a wallet address if you want to verify this on chain or if if you're a web application you can um attach this to UID um which is a standard for for user identifiers Great. So, uh the current coverage here is the the current coverage of uh self you can directly go on map.

xyz. So the the complexity behind the pro the project is that identity document like passport ids ADA which is a local ID solution in India they don't use the same signature algorithm and hash function meanings that we had to do most of this implementation oursel but now most of the job is fortunately done so um you can check the current support on maps.xyz XYZ and also if you're curious about what is um your country using as a signature algorithm you can just hover the country and you will have the details about about that. All right. So um we started by supporting biometric passport but for HCC we plan to release the um support of biometric IDs like the EU ID cards but you also have some other countries that are outside of EU that is that are still using biometric IDs um like Saudi Arabia for example but many more of course.

If you are curious just try to scan your ID using self and you will see if there is a chip inside. Um for for now to scan it and to register into self you need um you need a chip but uh most of all you need a digital signature that you can verify inside inside the proof. All right. And um if you don't have a biometric passport or biometric ID then I'm going to show you but it's extremely simple to generate a mock one to build on top of self. Of course you won't be able to use that one to to visit other countries.

All right. So what does the experience look like and how does it work? Well, the the phase is into time. Um, I'm not going to linger on that because it's extremely related to cryptographic gadget that we are using to make you fully anonymous. But first, you need to register.

Um, and to do so in my case, I'm going to scan my biometric passport using the NFC of the phone. And once it's done the it means that the digital signature is on boarded inside the the mobile device and you can start generating the first zero knowledge proof about you. So uh here is the flow. We try to keep this quite uh quite short but according to the signature algorithm used by your country it can be I think up to up to one minute. All right.

And when it's done, so yeah, just remember that at this step so far you don't reveal anything about you. You just prove that you own a valid data station and that's it. And in the second time, you have the disclosure proof and that's pretty much what you should be interested in. So in this one, the flow is the following. uh user are going to scan a QR code or click on a button to open the self app um and by doing so is going to be prompted on screen what are the information that this application is requesting them to to disclose and then they can just click on confirm of course they have to acknowledge it and then they can confirm this and it's going to generate the ZK proof on the on the on the background and send it share it and this proof can be relayed directly on chain.

So you don't even have to think about gas fees. Um our infra can really it or can be sent in case of a web two app to um a backend server. All right. So if your if your application is desktop based then you're going to generate a cure code using our SDK. And if it's another mobile application then you can just generate a deep link using our mobile SDK.

uh you create a button open save people click on that button and t you will see the screen all right so here is um the global architecture um such that you know so uh people scan the passport or the biometric ID uh it's stored inside uh your keychain so we don't see the passport data we don't store the passport data obviously because it's like the main idea of the protocol is to be privacy preserving so we don't do such things um everything is stored inside the mobile application and we used to do current side proving before but because the current state of ZK proving is what it is uh we decided to offer the proving inside T's which are blackbox so the mobile application is going to connect to the T which emit an attestation and inside this stationation you have the hash of the code who's running zooming inside so um this way that the mobile application is going to know that this service can't do anything else besides generate the proof and remove the passport data and that's it and finally these um the T is going to send it back to our infra but this time the proof not the passport data which are going to be relay relayed onchain or offchain as said before. So let's take a look at the bunties because we are sponsoring this hackathon and we have a total of 10k in bonties. It splits in two categories um the onchain integrations and the best offchain integrations. And for the best onchain integration we have a total put price of 9k with 5k for the first one 2.5 for the second one and 1.

5 for the third one. And for the best ofchain integration which is a bit easier of course we have 1k which is already pretty good. All right I think that it's time to start learning directly by doing and for that let's do it together. Um we created a repo for this workshop. Um you can go directly on self XYZ organization on GitHub and look for the workshop repo and you just have to clone it.

So the structure of the repo is in two parts. Um you have the app folder and the contracts folder. In the app folder you have a next JS application because if you remember well um you can verify the proofs either offchain or onchain. So in the next J nextJS application you will have the front end parts which allows people to scan the pure codes but you will also have the back end which can verify the proofs. In the contract repo, you will have all the scripts needed and boiler plates to um deploy a smart contract to verify the proofs directly on chain.

So um in any case you will have to run the the app repo and then if you want to verify the you you will see how to do it exactly but um in the front end part you are going to set up the endpoints and it's there that you are going to choose hey I want this proof to get verified on a smart contract or I want this one to get verified on a back end. All right. So let's do it. So I cloned the repo here. Um the first step is obviously to init the subm modules.

So what you can do for that is just cd app b install. Do the same in the contract repo cd contract b install. So I'm using bun but you can use yarn or npm2. I think that um anything is valid here. Um then you want to run the next JS application and to do so you can just do rundev and then if you go to localhost 3000s you are going to see this beautiful front end page and oh the the QR code is loading it's loading because um actually for the front end SDK you need to set up an endpoint and this endpoint it has to be either a smart contract address if you want to verify the pro function But if you want to verify the proof of chain, then it has to be a public endpoint.

So let's create this public endpoint because it's not going to work with Lucario 3000. So personally to create public end points, I use nro. It's super convenient. Um you can do the same nro http 300. [Music] And here it is.

And then if I go to myv, I can just replace with what was committed here. And if we reload the page, the clear code is here. Now you need to scan this code. Uh you can just try to scan it. is going to ask you to um download the SE application if you don't have it already yet.

If you do have it, then you're done. Uh still I would like to show you something in case you don't own a biometric passport or biome ID. Let's see together how we can generate a mock one. So here is the first screen and if you tap five time here you have the developer mode. So then you can choose the your identity.

Um today I feel bit gem. So I'm going to to pick that and then you're going to generate these mock identity documents with like a a real signature behind that you can generate zip proof with. So here is the next screen and once it's done it's going to start to generate the zk proof. So, as I said before, um, we try to keep this quite short. You can see that it's verified.

Perfect. All right. And then I'm ready to go. This is the home screen. And from there, you can scan the shortcut.

You know, if the mobile application is connected if this little lead element uh turns green. And if that's the case, uh you will see prompted here all the um information that this app is asking me to disclose. So for now it's not asking me to disclose anything, but let's let's change that. So we can go to page.tsx.

All right. And if we go here, we can modify the different disclosure attributes. So if I unc comment this line, if I do this and then I go here and refresh the codes and I scan it again, now I'm going to see that this app is asking me uh to disclose that I am over 15 and that I am not a citizen from North Korea which is what we were expect expecting. Uh you can also ask people to um to disclose um information directly. So um if you put true on the name or true let's put true on the issuing states um and on the date of birth.

Then if you go back here, you refresh the page, you scan it again, you will see that now it's asking me to disclose all these different So let's get this pro verified. Um just to prove this one is way faster than the first one and we are still going to optimize it. All right. And that's it. Identity is verified.

Yay. All right. Uh so now let's tweak a bit more the different parameters that we can have in the back end. So um if you go in roots ts which is in app api verify uh you will see here the different um the verification config. So what we can do is um do a proof that is not going to to work just for free.

So you can we can add in the excluded countries countries dot pigon because I have a pion or one I would say. So let's do it and try to verify again the proof. All right. How to verify The proof is generating and wow this one got refused. So um I got the error displayed on screen invalid forbidden country lists.

Oh this is because actually actually this is another issue which is quite interesting. It's because in the front ends um in the app one Yeah, exactly. That's why it's because whatever you have in the front end, you have the you need to have the exact same thing in the back end. That's that's super important. So, if you ask someone to um prove that he's not part from a specific country list, um you need to ask him like if you want to verify that, you need to ask him to to prove it first.

So, Let's get back into it. Scan the CL codes. Generate the proof. And this proof got refused of course. And this one is a bit different.

Um this one means that actually the proof failed to get generated because the assertion that you're not part of the country list is happening inside the zero knowledge circuit. So that's why this error code is is quite different. All right. Um, I think you can at this point just uh put on pause this this video and just check out the documentation uh and see all the different disclosure attributes that you can play around with. Um, because in the front end I disclose the like my issue country I could play around with in the back end.

So maybe we can try to print it. Um, or maybe let's directly move to to the smart contract part. We have a lot of stuff to do there. All right. So, just a few things before we move to the smart control verification.

Um, so inside the C code SDK there, there are a bunch of parameters outside of the disclosure attributes that uh you need to take a look at. So, um the version you can just point put to that's the latest one for the app name. um that's what's going to be displayed inside the mobile app when you scan it. Um the scope is something that is going to be unique for each application. Um so whatever you put is going to get hashed again with the smart contract address or the DNS.

So um for this one you can just put self workshop is going to be to to to be good enough. um the endpoint that's what we set up inside the uh this one has to be a public one if you want to refer the proof chain that's where you are going to put uh the contract address then you have the logo B 64 so actually you should put uh URL to a PNG um that's that's recommended instead of but putting the the base B 64 of the logo will still work but uh I would I will do it first Uh then you can put the user ID. So the user ID for here we put the the zero address but you can put something else if you want. Um we actually accept both if your address or your UID. Um, if you want to use Ethereum address, then put hex as the user ID type.

And if you want to uh have a UID, which is quite the norm for for web two, you can put your UID here. But let's keep it as all right. For the endpoint type, okay, so this one is quite important. Um so if you are using a book passports you want to use the staging environment. So the endpoint type is going to start with staging and then if you want to verify the proof on the backend server you are going to put https and if you want to verify it on chain then you can put staging cell instead.

I think you can see the typing here. All right. Yeah, you have these possibilities. So, uh staging Seno or Seno HTTPS or staging HTTPS. So, if you are hacking with a real passport or real ID card, then um put just HTTPS or cell instead.

All right. And then for the disclosure attribute, so you can take a look at the documentation to see uh all what you you you can disclose. But um what you can understand is that you have two different kind of um features. You have what you can ask the zik proof to verify directly like the fact that the person is above a certain age, the fact that the person is not part of the of sanction list or um that the person is not part of a country list and then you have like what you want to ask the person to reveal. And for for this one um you will need to perform the logic yourself inside the back end.

So in our case in root.ts um so here that's how I can get back the um uh the attributes. So um all right I could do something like subject dot experate and then like play around with the with the information from user credentials but you need to implement your own logic with that. All right. So I think that now we are ready to switch to the smart contract verification.

So for this one as we said before you can go in the smart contract repo um just it's bun install bun install and then you have to go in the env set up the different parameters. So um what you have is the private key of your wallet on co uh the solos scan IPI key which is just if you think it's just the traditional ether ether scan v2 uh api key then you have to put the identity verification hub so it's already it's already inside so this is the one for set test net Um if you are hacking on sale mainet then you can um just check the documentation to have the smart contract address and finally you need to put a verification config ID. So um there is the default one and the default one don't check anything and this verification config ID it's the same thing as what you did in the back end here. So that's the same thing as that you know where you can put um excluded country and minimum age or that's already done and the off check. All right.

Once it's done um what you can do is build ren deploy and it's going to deploy the smart contract. The smart contract is here. If you go in proof of human soul, you can see this the the code of the smart contract. Um it's implementing the set verification routes. That's a boiler plate that you can reuse.

But if you want to do something that is more custom, you just have to implement uh our smart contract SDK and um our smart contract SDK. and inherit the self verification root uh class. All right. Uh then inside the constructor inside the self verification root constructor what you need to put is the the hub address. So that's why we put it inside the NV.

And I also need to init the scope. So the value of the scope um if you check the deploy scripts scope so we put one that's a mock scope here but if you go to um tools.xyz which is going to be your best friend for for this um hackathon I hope so actually uh you will have a tool to generate the scope. So here what you want to do is put the smart contract address and put the scope seeds. So um if we get back to um here we have the contract address.

All right. So let's put it here. And for the scope seed the scope seed is what you put in thev of the app repos. So this this is the scope se. All right.

So you just have to copy paste it and then you will have the final scope. All right. So what's what's the idea behind is when people are going to generate a proof they're actually going to generate a new identity for this proof such that if I generate a proof for app A and another one for app B nobody can actually link these two proof together. So if for the first one I disclose that I'm above 18 years old and for the second one that I'm not part of the offer list, nobody will be able to link all this stuff like all this proof together and kind of um assemble all these pieces of the puzzle to know who I am. And to do so uh you hash your identity with um the DNS and the and the scope seed inside the do this inside the GK proof and this is to make sure that your proof is going to get consumed by this application only.

So that's why when you scan the QR code you also you actually see the end points on the mobile application and you can see the contract address where the proof is going to get consumed or the DNS where the proof is going to get sent. Um and on the on the smart contract side or on the back end side um you want to make sure that this proof um was really targeting your smart contract or your back end. So that's why you want to put that. All right. So you just have to copy the scope.

Then you can go into um set scope.js. set scope.jis and replace the new scope with the value. Um, and then we can just do burn set scope and it's going to update the scope on chain.

All right. So, we can see that it's can we see the contract address by the way here? the project is it the same one? Yes, the correct meth. So now the scope is set um the the verification config ID is set to oh by the way if you want to change this one uh once again you really need to go to um the developer tools and you can directly here you just have to um modify the verification config and click on this button and it's going to um give you is going to send the transaction to the hub and give you back um the value of the verification config that you want to use.

All right, so let's get back to it. So um my um my verification config is set my scope is set. I'm already ready for the verification. So I'm going to take the contract address uh go inside the MV of my app repo and change the endpoint for this smart contract address. All right.

And then so for the public scope um we keep the same and then all right this is this is the thing here you need to update it for cell or staging cell. All right, let's get back to our front ends. It's got the codes. We generate the proof. The proof is generating.

Uh it's going to take a bit more time this one because you also need to wait for the onion verification of the proof and it's done. So um let's go to senoscan. Do we have it here? All right. verify self crew.

So this is my transaction that happened uh 20 second before and yeah that's that's pretty much it. So now what I can do is read the contract just for fun. So here let's not mind about this function. So you can see again the value of our scope. You can see the value again of um the verification config that is settled the verification config value like the ID um and then what's fun is you can get the last output.

So this is by design of the this boiler plate but if I go here I will see the value of the different fields. So we are going to change this right now. Um so there is attestation ID this one is two it means that um I used a mock ID cards if it's one it's for the biometric passport then what do we have the user identifier the modifier the ID number nationality date of birth gender all right um but if we do change stuff like Here we ask the person to disclose let's say the gender and let's say the nationality. Uh yeah, of course. True.

All right. So, the proof got verified again. um but this time if you query you can see that the nationality got disclosed um with be which is the country through alpha code for Belgium and you also have the gender and that's a boy cool what else can we check inside the smart contract that could be interesting or maybe you want you probably want to use the address inside the smart contracts Uh do we have last used address in the reset or oh there is last user address I see here. So um last user address it's the zero address. Um it's the zero address.

But if we put something different here like let's go to vanity address. Let's generate one. Let's do something like uh self. This is this is totally not mandatory of course but all right let's take this address just because it's a bit fun then I can go back to page.tsx and for the user address instead of the if you're on zero address I can put my vanity address which is starting by self and then a zero.

Wow that's how how cool is that? Um yeah, I just have to do that. I go back to uh my front end. I scan it again. So you can already see that on screen is displayed the Ethereum address.

Um let's Let's generate the proof and the proof got verified. All right. If now we get back here [Music] last address and here it is. Sweet. Cool.

So, I think that's pretty much it. Um I think you know almost everything on the different SDK that we have. So to sum up we have a front end SDK that is going that is actually used to ask the person to disclose stuff. Um you can use the QR code SDK to generate a QR code inside your desktop based application or you can also use a deep link SDK to generate a deep link that you could call from within an web application. And on the verification side, you have two SDKs.

The TypeScript one to verify the proof inside um a backend server and the smart contract SDK if you want to verify the proof directly on it. And coming soon um coming soon you also have the mobile SDK that would allow users to complete the whole flow. the registration and the disclosure without having to leave your mobile application and to run the safe one. And that's it for this workshop. Thanks for your time and I hope that you enjoyed it as much as I did and I can't wait to see what you're going to build on top of [Music]