Welcome to the self workshop. Um, thank you for coming here today. My name is Remy. I'm co-founder and working at self which is an identity protocol that lets any third party application web two or three to verify the identity of their users while letting them stay fully anonymous. So the plan about today is first for me to give you a better understanding about the projects what is the vision behind then we can talk about the bunties because we have like a total of 10k for this hackathon and finally you will see with uh Nikico and Aman to see code implementation and how you can integrate the SDK on chain or offchain.
So why self exactly? So let's let's say that you have an application that needs to verify the identity of your users online. Today you are probably going through the traditional KYC process which is extremely painful. Um I think I did it something like five or six time in the past few months and each time that's such a pain. You need to find your ID document um scan it send information and then wait until the verification and also you need to pray that these information that you're going to send and that are going to be stored inside database are not getting hacked and like this kind of hack this can happen of course so this is definitely not secure and even from the application point of view that's not secure neither because using generative AI Now it's childish to generate fake image of ID documents or use um or just use deep fakes for example.
So um yeah definitely definitely not secure at all. So how can you solve all these issues at once? Well I think that's the moment for me to talk you about biometric passports because these are pretty cool. So biometric passports uh you can know if your passport is a biometric one if there is on it this this little logo which means that uh inside the passport there is a biometric biometric chip which contains all the data that are signed by the country means that you can verify this signature inside the zero knowledge proof and this is exactly what you're going to do using self. So um by doing so you can already generate a zk proof that you want a valid passport means that you are a real human but you can do even more than that because you can prove that you can basically prove anything that is related to the information that are stored inside the passport such as I'm above 18 years old I'm part or not part of a specific country or that I'm not part of geopac list for example without revealing anything else which which is extremely important.
So um right now we are supporting biometric passport but we're also working to extend the support to other ID documents such as the ADA which is a local ID solution in India or the EUID cards and if you don't own a biometric passports uh that's not a problem if you want to try to hack on self because um you can generate mock passports within the application but of course you can't use this one in the in the real life anyway. Um, so what does Luke's self exactly? So for the for the end users, he's going to open up the mobile application, scan the passport using the camera. It's just reading some fields, then scan it uh using the NFC reader of the phone. This is maybe the tricky part.
Uh the NFC chip can be on the back cover, on the middle cover or in the front cover. And then you are going to generate a ZK proof in which you are going to verify the digital signature of the passport. And then that's it. uh you you are good to go to yourself. So from the developer perspective, you are going to in the front end generate a cure code that people are going to scan using the self application and it's going to be prompted inside the mobile app the different disclosure attributes that the user will need to disclose.
But you won't learn anything else beside this information. So as a user I will scan the QR codes uh generate another ZK proof and send it to the third party application. So what can you prove exactly using self? As I said anything that is related to the passport information like birth date for example we are running a small experiment in which if you can generate a ZKP that um your birthday is in the current week you can earn a 100 bucks which is pretty cool. Then there is expiry dates, the name, the surname, the passport number, the gender, um the fact that you're above a certain age.
There is also the nationality, uh the fact that you are not part of a given country list or not part of the offax sanction lists. So the last one are extremely important and extremely interesting for compliance and we would love to see them in real defy applications. All right, so let's talk quickly about the bunti. So we have a total of 10k for this hackathon in two categories. The first one is onchain and the protocol is based on coil meanings that um if you decide to verify the proof on chain you can accumulate both the prices of cell and the one of the second one is if you want to verify the proof of chain so in a node server for example or on on another blockchain.
All right. Uh then if you want to talk about the code example. Yeah. So how do you go about integrating self into your app? The first so there's two components that you must look out for.
There's the front-end SDK which has the QR code component and what you can what this QR code encloses is the disclosure options you want to verify for your user. For example, you can configure your QR code to have your options to be um where you want to generate the proof, the date of birth of the user and whether you want to verify it onchain or offchain. That's the first component. And the next component is the backend SDK. So the backend SDK verifies the proofs and this can be either onchain with our core with our um contracts SDK.
So this involves um extending an abstract contract and um overriding a function the verify self-p proof function or it can be offchain which is a NodeJS SDK where you can just verify your proofs on the on the server. So this is what the QR code will eventually send the proofs to. So h how does this work? So you have you generate the QR code on your app on on your web or you can do it on your mobile app. And what you're going to do with yourself with your self app is yeah what you're doing what you're going to do with your self app is you're going to scan this QR code and when once you scan it you get all these options that you want to disclose.
So once you approve this request your your password details get encrypted and sent to a TE server and that's where the ZK proof is generated. It is generated by us and that's sent to the contracts either depending on whether you want to verify it onchain or whether you want to do it offchain and yeah the QR code and self app listen to the contracts or the backend verifier and you get the verification result whether it's the success or failure or not. So how how do you do this in the front end? So you you see you you have this QR code component and this builder component and you you have this endpoint that you have to specify. So if you're doing it offchain then you need this endpoint to be accessible everywhere because our TE servers are going to call this endpoint to verify your proof and the endpoint type is either cello or https or like there's other options in our docs whether you want to do it onchain or offchain and you can see here it's a so this app for example is the happy birthday app and what we did was in we started this in ETH Denver if your birthday lies within one week of today like a one week window then you get um 100 USDC sent to you.
So what we are doing here is we are disclosing the date of birth and checking whether your date of birth lies within the one week window and yeah you you wrap this up in a QR code component and yeah scan it with your self app. Uh Nico will talk about how you can do the contact. Okay. Okay. Um so I will explain like how to like integrate our back end side to your applications.
So there's a two ways as as explained um the events there is a contract integrations contract verifiers and web two verifiers but like for the web to verifier is not really hard to integrate there is a great documentations uh on our website. uh so like I would I would give you a little bit explanation how to integrate a contract uh to your applications and it's more it's more like you know prize right so uh we have example applications named happy birthday happy birthday contract is like so verify uh the data in the passport and liio your date of birth to our applications and verify like your like a date of birth is like a between uh five days windows from today and if if it is a five days windows then like you can get a five $100 or something. So um how to like uh like integrate our contract first you need to um like uh like import and inherit self verif verification route. Uh this is a abstract contract and you inherit this contract and like initialize uh with these values and then there is a one functions named verify self-p proof and you will override that functions and write your own verification method uh in that functions. uh why we have like this abstract contract is because uh we have infrastructures like applications or TE servers to generate a proof and that T server will call automatically call your contract.
So like we need to have like some fixed uh like an interface for that. So this is why I we provide abstract contract named self verification rate. Um so right now I don't really deep dive into like each various uh you need to input for like a initialization of surf route. Uh you can go to docs or like you can just uh come to our various and like ask some questions. But like first you what you need to do is like you just uh import this uh contract and like initialize in your contract.
Then like uh after you initialize you need to write your own like a verify self-p proof functions in your contract. So like first uh like override our functions and there is a three basic verification you need to like I recommend you need to add into your uh smart contract. uh first is a scope verification and the second is a attestation ID verification and the third is uh like a proof itself verifications. So uh scope verifications like uh scope is kind of the name of your uh like applications. So like uh we verify so like you need to verify it that proof is generated supposed to do use for your applications or not.
So like I recommend you to add this scope verifications and also like you should add attestation ID verification. So attestation ID is uh identifier for each document. Uh currently itself is only support the passport. So like right now it's not really matters like future we going to support other like ID card digital ID card like for example like UID card like adult. So like for that we added this kind of identifier.
So like it's not really matter right now like I recommend you to put this verifications in your contract. And the third of course you should uh verify the ZK proof like gross 16 proof in your contract of course right and of uh and then not only like these basic verifications uh you can utilize like attributes which is inside a passport. So inside the passport there is like so many like a personal informations like name or date of birth like gender or nationalities and also like not only like not only like verify those like direct you can also prove like you are more than certain age or like you're not from certain countries. So like um I it's also like I'm not really deep diving into like a how to like a verify each attributes here but like like basically what you need to do is like uh there is a so like in a public inputs of of our proof uh there is a li data packed uh field in our proof um you can find the index of these values in our uh contract there's like a contract constants And then there is a three array of the Uint 256. So like first you just get a reveal data packed for three three UN 256 and then give it to our our library named formatter and get our one packed by data and then one pack and then like you uh like extract some part of the data in one bytes data and like for example for this like you can get a data vers from one bytes data and then you can get the data vers and for the happy birthday contract uh we need to like a change uh like pray with this date of birth because like date of birth in a passport is like the year it's also included the year you born in but we just want to get the month and date for like a to verify to compare with the current date or not right so like we just get we are like you need I added some like lines lines of code to like uh play with the data bar uh if you want to play with data uh like happy birthday then like you can copy it.
But maybe like there's more use cases like you have more ideas on the contracts like uh I can help you how to play with other attributes in the copasport. So like you can just come to our uh booth or like it's also we have a documentation on our website. So like uh there's um explanations of how to integrate a contract or like how to integrate our backend verifiers. So like yeah you can just refer it first but it's also come to obvious if you got questions and this is a link to our GitHub and uh this is a link for our website. So um yeah you can just uh come to this web page.
So yeah this is pretty much everything and I pass it to the Remy. Thank you Nico. Um yeah, one point that I would like to to raise is just make sure that you are going to put the same arguments in what you are going to ask the users to disclose and then what you want to use in the back end like like in the back end or in the smart contract because if you want to access to uh let's say the passport number or the name and surname, you need first in the QR codes to let the users disclose it because they are not going to reveal anything besides what they are going to verify. inside the mobile application. So that's that's super important to know.
Um then I think we're we're good to go. Um yeah, thank you so much for your time and if you have any question, we'll be pleased to to answer to them. So we used to do client side proving but uh we switch to TE's now. So the the proof is generated inside and like of course the end game is to use back client side proving but because the countries they are using different signature algorithm and hash functions there is a map that you can see on map.sell.
xyz it's extremely hard to like there is a bunch of zik keys that people should download in order to generate the the proofs and you can ask you can't ask people to download like a 10 gigs file in order to generate the proof. So um right now it's in the tea and we plan to move it back inside the the mobile application but we don't see the passport data. We don't store the passport data just passing through the tea generate the proof and then good. Thank you. Any other questions?
Yes, please. All right. So the passport data is only stored inside your phone and that's it inside the secure the secure elements of the phone. We don't store it. Yes.
So you need to speak a bit louder please. All right. That's that's a super good question. So the question is about uh the structure of the protocol itself because I didn't detailed it but the protocol is actually in two times. First you are going to generate a first proof in which you are going to verify the signature of the passports and it's pretty similar to tornado cache or simur if you are used to these ones.
So first generate a proof of passport in inside of which you are going to verify the the digital signature of the passport and generate a commitment which is a hash of a secret and part of your passport data and you take this commitment and you put it on chain on the commitment merry meanings that in a second time you can reuse this commitment by doing this time a proof of inclusion of this commitment inside the tree and disclose any information related to your passport data. But this proof is extremely cheap and we plan to bring it back extremely soon on client side proving because it's like totally adapted to to ZK proving it's just proced hashes no signature verification. All right. Uh we still have time if there is other questions. All right.
So, uh on the left you have the the link to the GitHub. Everything is fully open source. So, uh you can just check the repositories direct if you want. On the right you have a link to uh the website in which you are going to have like other links to the documentation uh to the map I was talking about before and a bunch of other information. Um we are maintaining a blog that you could you could check that is named not to self.
So yeah please scan this QR code and check this out. All right. Thank you.
Automatic transcript — names and jargon may be misspelled.