NoirHack: Library Workshop - ZKPassport SDK

Transcript

Hey guys, good morning. We'll give uh just a minute or two to let people uh join from the Discord and then uh I'll introduce Theo. How's it going? Hey, doing all good. Awesome. Awesome. Cool. Well, uh it's uh being recorded. I'll go ahead and uh just kick things off um and then let people join. Um but yeah, uh good morning uh GM GM uh everyone that's joining us and everyone that's uh

checking out the recording. uh and welcome to our first uh Noirhack library workshop which is focused on uh the ZK passport SDK. So I'm super excited to introduce Theo from ZK Passport. He'll be guiding us through this session. So what makes today uh particularly exciting for this workshop is it represents the first uh unveiling of ZK Passport's onchain verification uh capabilities. Something that isn't uh even documented yet in their official materials. you'll be getting an exclusive first look um at uh onchain verification with ZK passport. So ZK passport leverages uh ZK proofs to enable privacy preserving verification of passport data. So this allows for a bunch of interesting and cool use cases

for verifying important information some of which we'll get into uh and explore with Dio today. So he'll walk through the SDK um and how it works. he'll demonstrate some of the functionality and then showcase this uh onchain verification um for the first time. Um so Theo uh I'll let you take it from here. Um cool. Well, thank you for the intro Rafi. So as uh Rafi mentioned uh so we're using passport and ID card uh to essentially verify information about you. Now what kind of passport? It's essentially like this one. Actually you can't see. Oh, you can see it. So this is a regular passport. Uh it also works with ID card as well. So something like this if you can see it. I think I should

deactivate my blur but unfortunately but I you can see the the gist of it. So it's all kind of documents identity documents issued by government um your government probably issue something like this and that has a chip in it an electronic chip. So you can leverage this because this data is signed by the state. So information about you such as your name, your birth date, your um document number, any kind of information you can see on it and some other stuff that's also hidden inside your chip um is signed by the state. So what we do is that we leverage this and we verify this within a zero knowledge proof using noir. So all of

our circuits are built using noir and all the verification is done within our circuits using Baratenberg the back of a tech to generate the proofs. Um I'm going to share my screen. It should be easier to present that way. All right. So um just to showcase I cannot do a proper demo. It's a bit harder to do with the app. But the idea is you would take your phone. Um actually let me to deactivate my blur because like this is going to be annoying otherwise.

So, where's that video? And there you go. Oh, much better. There you go. So, you would take your phone, like any kind of phone. Most smartphone nowadays have NFC capabilities. Those chips are NFC enabled. And you would just put it behind your phone and it would read the data with the app. And same thing goes with passport. Same idea. And so here with the app you can see every everyone can see my screen. I didn't ask just one confirmation. Yes.

Yeah. Yeah. Okay. Cool. So here you see the that's the screenshot you will get in the app. So when you start the process you scan what we call the MRZ which is the machine readable zone. So those two lines of information like numbers and letters at the bottom of your passport will contain all the information to decipher the information and authenticate with the chip of the ID. So once you've read that all this is done locally, you will move to the next step which is scanning the actual ID um with the with your NFC capability and then you would eventually have them in your app. And now we also added a new feature where you can have several IDs in your app at the same time. So for example, this is

for mine. I have both my national ID and my passport in it. Both of them works. So this is the general idea. Um the overall standard is now permissioned in a sense that state controls it. It's like more like a not fully permission but somewhat permission standards which is set by the international civil aation organization the which is a subsidiary from the UN United Nation and then the one that kind of set the standards and the states have to follow them. Sometime they don't respect the rules but uh that happens but most of the time they do and so the core idea of like that idea of signing the data is that the passport is signed by the intermediary certificate which is self assigned by the root certificate and what we have at ZK

passport is that we have like this certificate registry which contain all the certificates on most states and that we able to prove essentially that your passport was signed by one of them and by the way by that process we have the trust anchor the state. So this is a pretty strong assumption if you trust your government. Not not all government as as trustworthy all the others but uh most of the time you can. So this is the general idea. Any questions so far? Before I move on to the more tech side of things for anyone with questions, you can ask in the chat. Uh you can also just ask in the Q&A.

Okay, good. Well, I think I'll carry on then. Um, just to show before I move on to the tech part. So, this is the map of all the countries that issues um electronic passport sometime called biometric passport. So, essentially passport or national IDs with the chip. So, it's a pretty good coverage. Now, not every country, not in every country people have passport. But if you take for example the the EU, you must have at least one national ID or passport and national ID or transitioning to electronic. So that that's the joint.

So how to use ZK passport? I'm going to show the little demo here. Um and this is available on demo.zkasport.id. Oh, actually if you want to get a head start and download the app now because you will need to essentially try out the tooling, uh you can go on the website zip passport ID and click the download button and scan the QR code here for iPhone and here for Android. So I I'm not going to leave this on because I want to move on, but you can go on zap passport. ID and so on demo.zip Zig password ID which you can access from the main website. You for example I would open this and I can scan with my phone

and that will initiate a connection. Wait, let me just switch to my other ID actually. Yeah. All right. So that will initiate like a end to- end encrypted connection websocket connection between the phone and the website and you click on confirm and it sends back the proof uh to the website. Let me just open the console logs. Oh, I got lost. The websocket again got dropped.

[Music] So here it proved that you that I'm over 18. So what you see here are all the proofs. So this is what we had until now and it's still available here. It's pretty fast. It takes a few seconds. So this is uh what we call the fast mode. So you get all the proofs. So those two proofs verify the signatures. Your passport data. This is a data integrity. So checking the integrity of your data. And the final one is the disclosure proof. Essentially here verifying that you're over 18. So those are four different proofs but they all linked together using commitments and then you can get the result here. See can 18 over 18. Yeah that's true. And then unique identifier here which is also returned.

This is essentially something some kind of identifier which we sometimes call nullifier but we call it unique identifier here which identify uniquely your ID. So this will be the same for the same ID for the same website. I will come back to that a little bit later, but this is the core idea. So if we go to our docs to integrate ZK passport, it's pretty easy. You just install our npm package. You run this and then you can import it and there's no registration, no AP, no API key whatsoever. This whole process can be done without any other um process, any other signup. So you import

the SDK, you can set it up here with your domain name. So this is important because essentially this will scope what I mentioned before the unique identifier to your uh domain name. So that way they're not the same on different domains. So there's not like cross reference and trying to essentially track track people across different websites. And if you do this in the browser, you don't need to specify it because we can automatically detect it. But if you do this in OJS, you need to specify it. And then you can build a request. So this request you specify here the name of your app, the logo of your app, the purpose, what you want to do with that information you're asking, and the scope. You can specify it or

not. This is optional. This is even more scoping uh on top of the website domain. It also scope to a specific use case. For example, if you want to have an identifier which is specific to a use case. Um and what it will look on the app when the user scan the QR code is this. So you have this access request page will show your website name, the domain name, the logo and then the information that you're asking with some information that user can see and the purpose at the end and they can accept or confirm. And once you've done this, you got a query builder and you can use that to simply

um disclose the information you wanted. You discuss your first name. You check that you're over 18. You check you're within a list of countries like your nationality from a list of country. Here we have some constant like EU countries for example, 27 countries. And you check that you're outside of certain countries such as Sweden, Denmark. here just using for the example and then you can use the URL which is return to build a QR code or directly build a button or link the the user can use to click on if it's directly using your app on the mobile phone. That way it redirect him or her to the mobile app to do the rest of the process. And we also have a bunch of events you can use uh to follow the

process. So on request on request received means that the user scanned the the QR code and he has received information on his website on his on his phone. Essentially he sees that page here that you on the screen and then generating proof essentially says that the user confirm and it's currently generating the proof. On proof generated it means that the proof was generated and that you starting to receive them. On result is when you actually received all the proof and you received the final result and on reject if the user actually decided to reject the proof the the request and on errors if you have any error in during the process. So I will show quickly how this all plays out

with our SDK example. So I have it running actually I'm going to show it here first. I have it running here. So this is similar to what I've shown before as the QR code. You can see request received. So the request received event was called so you know when the user actually scanned the QR code. Then you confirm they confirm on the phone generating proof and then proof received. It's pretty fast. And then you get back the information. So first name, EU citizen is over 18. The unique identifier and then verified yes. So you can see all the information again in the

console as well with all the proofs. So how it looks like in code. So for example, here is ZK passport- Z um SDK- example which you can find here. So it's on our GitHub. So, GitHub DK passport/dkp passport-sk example. I'm sure I'm going to send the link in the chat. One uh one quick question Theo um in the chat about the SDK. Uh is it only for JS? Um and is there any other language support?

So, um the SDK is for now it's only for TypeScript. So, this is only a TypeScript SDK on the JS. Yeah, no rust SDK for now. All right. So, I've sent uh wait, not an API. Um um no, you don't have a generalized API in that sense. Um because you need to communicate with the websocket. a sec.

Um, the TypeScript SDK is a wrapper around it. So, all right. So, this is how it looks. So, this is a React um simple app integrating our SDK. You can see it's imported here. And you initiate ZK password here. It's using the host name here. So the domain name of the current website which is local host since I'm running it locally and then you build your current request. So here zk passport the logo z passport proof of your citizenship the scope and the mode fast. So by default the mode is fast which means it returns the sub proofs it takes a few

seconds and then you got the query builder. You build your query, you call dawn and when you call dawn then you can get the URL and all the callbacks and then you can use that to update the user uh interface and on proof generator you can get the proof which is proof result. It contains the proof vash some other information and finally the result where you will get the result of your request. So first name disclosed and the result here which is the actual first name or when you have a comparison such as whether it's within a list of country it will return a boolean saying whether it's true or false and that's essentially what you see on the website here that information

has been used to um display the result and yeah and the QR code This a simple like React QR code library you can use to you just put in some text is going to be the query URL and you have a QR code. Any questions so far? We've got a few. Uh it's up to you whether you want to answer some of them now or at the end. Um if you check the Q&A.

Oh Q&A. Wait, it's uh Oh, got it. Uh, so yeah, I'm going to answer some. So technically speaking, what was your main challenge you faced using Noir so far? Well, we started using Noir when it was still pretty early. It's like um I would say version maybe 0 two or even before that. Um and there's been a lot of breaking changing on the way. So there's been challenging to update the circuits um as it go as every update come. So they would break stuff and you would need to change it.

So it would make the process of like building a little bit longer but now it's a bit more stable so it's okay. Um at first the performance of Bratenburg were not as good but it's been severally improved and now it's doing pretty good. So that was also a main challenge we faced and otherwise it's definitely much easier than using Ciron. That was for sure even if we got early on the boat when it was still like very early language. Oh, also probably the lack of existing library which is why we built like a bunch of library to build our um old tooling and circuits. Um is it being used by any

commercial entity or country yet? Um as far as I'm aware um not really. We only have been so we have been used by Defcon um for the ticketing the discount back in November. So they run like a discount uh discounted uh ticket sale for Southeast Asian countries and so people that would prove they're from those countries they would get a discounted price uh for the ticket. So that's one of the integration we've been used for. Um otherwise a lot of people have been waiting for our onchain use cases our onchain like infrastructure to be ready in order to

use us. So I think that now we've just finished it or close to complete finishes because there's some refinement to be made um as I think it's going to become more and more um integrated more commercial entity as for country not really. I mean being integrating by all country that's another subject. I did opportunity to speak to the French government for age verification but not really integrating anything. And the last one please what did you guys use to build the mobile application for Zik passport? Uh I'm curious I'm just curious to how to use Noir with mobile application SDK. So we use react native

for the app like many others and we have built a whole mobile approving tooling uh which is uh called well there's several component to it there's BBRS noir RS which can be used not only in mobile but we optimize it for mobile which itself is used in swar which can be used with swift on iOS and no Android which can be used with uh Scotland for Android and all this is plugged back into React Native through the native module. So um that something that's open source which you can use. Um so actually let me show

it. Um so if I go in ZK patchport and I should be able to see no RS. So this is what we use at the core. So it allows you to generate proof uh with Rust and we use that on mobile and the way it works is that we wrap this in the library called SWAR which is also open source and free to use and allows you to essentially generate proofs uh in Swift which again we plugged into React Native and for that I do have a template that I probably need to update to the latest version but still not too

uh the Noir React Native starter. So if you clone this, you can have like a good way to start uh to see how to generate proofs with Noir and Baratenberg on mobile, both iOS and Android. Um yeah, so I'm going to stop now and we'll continue later with the questions. I hope that answer everyone's questions so far. All right. And so in terms of use cases, so you have some example in the docs, you can verify the age. For example, verifying you're 18 or between an age range 18 to 25. Your nationality, checking that

you're from a given country or list of country or is not from a list of country. Even residency. So for example, let's say you want to prove your residence of France. You can use some residence permit in Eur in Europe. closely they also use the same standard so they can be used for that. As for the topic of personhood, um you can have some kind of proof, but it's more one person, no one one ID, one account. So, it's not perfect personhood, but it does increase civil resistance because you don't have that many IDs as a single person. Generally, two or three maximum like I have two for example, a national ID and a passport.

So you can just not query any information and just send the request to the user and you will just get the unique identifier and all the information and that will be enough to have like more civil resistance. Uh you could use it for basic QC but for now there's some element missing to have like full KYC and we have like an example to do like client server interaction but uh you can look at it later. I'm not going to go over that. Um, and the new thing that we just added, so we've been working on this for the past few weeks, is onchain. So it's not in the docs yet, onchain um, interaction. So onchain verifications. So what that implied is that instead of having all those

subproofs that you've seen, those four or five subproofs, we recursively verify all of them into a single proof. So it's compressed into a single proof that you can verify on chain. you only have one verification to make which is way less expensive that if you would have to verify all those sub proofs. So this new mode has just been introduced. So I'm going to present it for the first time. And here's an example. So I already done it. Um you're going to have to bear with with it when you do it when you try it with your mobile app because it can takes a little while to generate the recursive proof. This is done through a server which is not yet quite optimized for like extreme speed but we may like

improve that later on. But the main idea is that instead of having all the subroofs you only have one here. Here you can see there's only one proof and that's verifying all the information you can see uh here. So this can be used on chain and the way you do it. So I have the example here in the EVM folder is that you replace the mode fast by compressed EVM and when you do this the app will um essentially send you back one single proof optimized for EVM verification rather than all the sub proofs. So this is frame primarily that and once you have the proof with the on proof generated you can use our helper function from the SDK

get solidity verify parameters. You pass it the proof like the proof result. It will answer with all the parameters and then you can also get the details of the verifier which will give you the address in the AI and you can feed that into Vim or Ethers JS and you will be able to interact with the smart contract. So this is how you would interact. Now behind the scene the SDK verify this proof directly on chain. If it's not a a compressed EVM proof, it will verify it with DBJS behind the scene directly client side. But in this case, it will verify it on chain. But here you can do it manually if you want as

well. Yes, deployed on Solo. Yeah. But now we going to keep with test net um as we refine the smart contracts and the certificate registry and circuit registry as well. There's a few other things we need to build, but like people can start building with cipoleia. That's a actually there's a pretty for for people looking for a faucet. I've discovered that Google has a faucet or sepoleia. It's actually pretty reliable. So you can get some testn net um if over there. Um so I think that pretty much covered this part. So this is the SDK.

Now if you want to do interaction directly in a smart contract. So I'm going to show how the verifier looks like. So this is a verify proof function. This is all the parameters that were returned by the SDK. So you don't have to worry about what they mean. The SDK will just provide everything for you and you feed it into the function and then we return whether the proof is valid and also the unique identifier. So how we use this this another contract here's an example.

So you can find this. I'm going to send the link actually. So it's in our repo uh circuit repo on GitHub. If you go into source solidity source sample contract. Let me send the link. All right. Um, and so this sample contract here, wait a

minute, wait a second. So this sample contract here has an instantiation of the Zika passport verifier which you can instantiate here and the idea is you would register the user. So you take the the generally like the the parameters necessary for the zig passport verifier as parameters. This is another boolean which indicates whether the user is using an ID card or not. It was this will be useful for the disclose information. Um and the idea is that you call the ZK passport verifier verify

proof function directly within your smart contract. You get the boolean whether it was verified and the unique identifier. You check that it was verified. uh then you check whether the user was not already verified and then you have a bunch of helper functions provided by the ZK verifier the ZK passport verifier which allows you to extract the information you trying to verify. So you have here for example an age proof which is contained in that proof. So you extract the minimum age and maximum age. So here you check that the current date is not in the future.

that for example the it's not a date that's been invented and you check that the mean age is 18 and the max age zero when the max age is zero it means like it's ignored so essentially it's like as if it's inexistent no bound so here it checks the user is over 18 and then you can get the disclosed byes from the what we I mentioned before the MRZ which is the two lines at the bottom of the passport that contains your name uh your nationality and all that kind of And then you'll be able to get use get disclosed data to be able to format this data. And so you can get whatever information you want. So for example where you can get the name, the issuing country, the nationality, the gender,

the birth date, the expiry or the document number and you have another one to get the exclusion list for example of country and then you can run your check that the example here is like checking whether the user is not from Spain, Italy or Portugal. And once all the checks are run, you can set the user to be verified, store his nationality and then associate the address of the sender to the unique identifier. So later when you want to do stuff, you restrict um port for register user only since the unique identifier will be always the same for your domain and for single ID. And you can also unregister as well

if if user for example want to change address and register to another address. So that's an example you can use to build all kind of like um use cases on chain but you will need the app remember to generate the proof so you can test things out. Uh we do plan uh but I can't put a date on that just yet to have the ability to generate proof with mock data. So testing process will be easier for people that do not have uh an ID that we support. So but for now you would have to use like an actual passport or national ID that is supported by

us. Any questions so far? Let me check um the Q&A. This one go to market. Oh yeah. Oh, another one. Oh, yeah. So, go to market strategy. Yeah. Um, and when it comes to this uh ZK passport is more like um a public good uh credible neutral. So, there's um it's like a tool people can build stuff upon uh we do plan to we do oursel building stuff on it like I mean we're going to do integration of this into obsidian the wallet on Aztec. We're

going to probably build some other stuff uh to um if some idea come to mind to kind of show people what can be built with it. But we do expect people to use it and not necessarily getting much benefit from it. Now there's some things that we may introduce in order to pay for the infrastructure cost but primarily the zik passport is a public good. So the go to strate go to market strategy does not really apply here with Z passport itself at least the the protocol um the unique identifier is different in every soul contract. Uh it's not really scope to your contract. It's more scope to the domain name to the website where you

generated it. So you it's not well it's going to be different most likely because like a different website will probably use a different s contract but if two website use a sim similar two website use a similar contract then that would be two different but if like so you get the general idea here it's like it's it's not according to your soul contract um if a stores that B stores nationality. I could get age and nationality that defies the same and I know about the logic of A and B that is if it was generated with the same uh

website essentially. So because the identifier will be the same for the same ID and same website because the scope is scope to the website and on the app what prevents someone to cheat um regarding the domain name is that the user will see always what domain's requesting uh information. So if the domain doesn't match the one on the website then there's something fishy and that will show up um in the SDK sample. How does it relate noir? So the the fact is all of our circuits are built in noir. So you not you could use the proof

in noir technically if you use like the fast mode or the compress mode but not the compressed TVM mode. But all of our circuits are built in noir. For example, here's like the age circuit. So this is a circuit in noir or you have like the signature checks. And if any of you actually need to do ECDSA verification or RSA verification in your project, you're free to um check our library for that. So we have no library in order to do this Noir CDSA. So if you want to check anything else than SEC P56R1 K1, you can do that. We have implementation for most n curves and most brainful curves which we

need for our passports. So we have like all kind of tooling you can use for no but like our own circuits are built in the wire. That's the main idea. Um thinking of using driving license as document. No we are not uh because this is an entirely different sender. So that's something that's to be handled differently. There's a few project that I've been working on this. I can't quite remember the name but it's uh completely different and uh working on something like proof of innocence. Um so we do plan to have some compliance in Obsidian but that's beyond just what ZK passport can provide. But ZK passport would be a

base for it and just not innocence. is just general proof of compliance is a bit more involved. Uh scalability that's still to be addressed. Um to be honest, um we'll kind of see this through as uh people use more and more and what I mentioned before infrastructure cost because obviously scaling will cost money. It's not we can't make everything for free. We'll provide people the ability to plug their own websocket into the SDK so they can use their own infrastructure by using our code. But by convenience, we also have like some own websocket that people can eventually pay for. But like we're going to always allow people to

use their own infrastructure like not pay for ZK passport and like pay for their own thing, but we're going to provide some tool convenience because we got to uh essentially be able to pay for the infrastructure as more and more people use use it. There's one or two questions still in the chat from Hiki which I saw Michael answered part of but they're asking what are you missing from being eligible uh as KYC if anything and then also just wanting to understand how it's verified. Um what do you mean how is verified? Oh she's asking can you fake it?

Oh um faking it is very hard. you would need access to the private key of the state. I think the only people that can fake it are the state themselves or like intelligence agency operatives. They probably have access to um the the private key or like for example some kind of agreement between like um rogue nation states. Like for example, I think it would be possible that in order to evade sanction a North Korean intelligence operatives would be would have a passport signed by the Chinese state. That could be something I could think of. But beyond that, beyond state actors, you don't have to worry too much uh about issuing fake passports like as long as you trust the cryptography and as long they're not using

Shiaan, which is unsafe. Um but actually there are some state using Shiaan like Russia. Um it should be all right like as long as the signature algorithm is secure, you can trust it. Um regarding KYC, what we missing to be eligible? Um so for KYC that's something we plan to a feature that we plan to add is face recognition. Face recognition. So you want to match the photo which you would do get from the chip of the passport or the national ID with uh the video of from the camera the phone that from the person that's actually generating the proof. So you want to prove that they match and you want to do a live check so someone is

not trying to stick a picture in front of the camera of someone else. So you need to do those kind of of check and we do plan to have this and once we have this this should be pretty much enough uh guarantee for KYC's uh basic KYC I'm not talking about AML and CTF those are different stuff which you need in case of like financial transactions all right I think I answer all the questions so far So um for to summarize if you want to start uh the ZK passport SDK is available on npm you install it and you can just use

the SDK example that I've shown as a base for um getting started with the SDK and then you can look I think it's been sent before yeah to the sample contract on the repo in order to see how to interact as for the address of the um verifier the SDK will essentially give it to you. So you just call like get get solidity verifier details and you will get the address in the AI and we'll update the address if it ever changes. So you don't have to worry too much about that. The SDK will provide everything for you. Um oh there's another question. Do you have selective disclosure? Yes. So selective disclosure is essentially let me show the code. Selective disclosure

is uh this so disclose function in the SDK you can disclose all the kind of information you can get from the MRZ you can disclose it so for example here birth date document number document type expiry date first name full name gender shing country last name nationality this this is all the information you can disclose specifically from um the mouse all All right, I think that answers it. So I think yeah otherwise I don't need to get

too much into the details but like that's the mobile app. Did everyone does everyone know how to access the mobile app? Actually let me just share the link just to be Sure. I'm going to share the test flight link. There's also an Android version, but for that you will need to go through our um registration form and then we add you to the list of um closed testers on Android. It's an open beta on um on iOS easier. So you need that the mobile app

and then you can use with the SDK and you should be able to try it out and then you can use the SDK to get the parameters you need for the verifier on sepoleia Ethereum Solia and uh we open to feedback if you found any bugs with the app. You may we're not supporting all the documents. Some documents may be a bit buggy and sometimes there's unexpected um data formatting. So we open to uh feedback so we can improve um these things and fix the issues you may be encountering. And um yeah, I I'm thinking about the channel where you could do that.

Um I'm not very active on Discord, so I'm trying to think what where people could like send me back messages. Um I guess Yeah, pinging me on on Discord might might work. Yeah, I will receive notification. Uh my pseudony name is just the same as here, Matt Ste. So, I'm can send it here. And if you tag me, oh, sorry, I should be able to answer on Discord.

Well, I think that pretty much covers it. Unless you have any other questions. No. Yeah. Awesome. Uh, we can take some more questions. So, Theo, is there anything else you want to walk through? I can also ask you maybe some some more questions.

Uh, yeah, you can go go ahead, I guess. Yeah, maybe you could share more about uh your road map for expanding like uh types of verifiable passport data. I know there's like different standards um and ways in which you support current passports. It' be interesting to hear how you guys are thinking about that. So uh the challenge with supporting different type of passport and national ID is like about the different type of signature algorithm that supported. So we support um oh and also hashing algorithms. So we support like a bunch of them now. So states are allowed to use ECDSA or RSA and they can use different parameters within this realarm of like two signature algorithms. So we

need to be able to adapt to all those in order to support all the documents. Um uh for now I wouldn't be able to put an exact number on what we support in term of document but we support though in ter of sign algorithm we support RSA nearly all of them except like some really unusual exponents but we'll detect them along the way as people like as we get feedback and ECDSA we support most brain pool and ECD and N curves with SA 56 SHA 384 and SHI 512 for the hashing algorithms. The main issue may be that some documents use SHA 2524, but that's something we can add support to. Not to

uh shouldn't be too difficult because you can derive this from CH 56 um implementation. The other issue might be Shiaan, but we do are wondering about Shiaan because Shiaan is not secure. So you're making a proof of hashing which is not secure. So we're wondering whether that's worth it. But there are some countries that still use it as I mentioned Russia also Lithuania some I think or even I think there was either Spain or Italy have some certificate that still use it but it's insecure. So you're making a proof of insecure stuff.

So I'm not sure. So the road map on supporting mobile passport is depending on this but also the mobile app and its ability to read properly all those and interpret the data properly because sometimes when we read the data it's not format as we expected and it's very hard to test because we don't have access to all the passports in the world. Uh so we kind of like flying blind expecting people that encountering issues to tell us enough information in order to debug it because since we are privacy first we can't collect any information unless the user actually wants us to send it uh to help us debug it. So it's flying blind which is kind of tricky unless we fly everywhere in the world and try to get a

passport from each country that's um or like sometime at conferences that can be useful since it's a bunch of people from all around the world. Um as for um I think the road map clearly for the next few months is going to be refine the onchain verification to have the certificate registry which is nearly ready for now. like a static registry but we're going to have a certificate registry that's going to be automatically updated uh by pinging the ICA registry. So the IAL is like maintaining a registry of all the root certificate from different countries.

Germany also has one. The Netherlands also has one. So we have like um Michael has been working on this um something that essentially downloads all those on regular basis and updates it as it's new certificate are added or removed. So it's going to be automatically um managed. So we're going to have like a more lively certificate that's going to support all the latest issue documents. So that's also going to have broader support with this feature. Uh we have the circuit registry that we need because we want the proof to be generated only by the circuit that we recognized because the circuit can be uni uniquely identified by its verification key. So we're going to use that to prove that when you generate

that single proof that you verify on chain that it is part it was all the circuits that were used are part of the circuits that we know are from us. So so that's something we're going to set up too. And then you're going to have the face recognition feature. We're still thinking about how we're going to go about it but we start to have like a pretty good idea. And we also going to need to have Aztec contracts to manage the registry on Aztec. So people can use the proof on Aztec. So just slight note regarding Aztec. If you want to use the AIC um you want to verify the proof on AIC, you need to use either the fast mode or the compressed mode but not the compressed EVM one. The compressed EVM

one will not work on AIC. This is optimized for EVM. The other two will work. recommend the compressed one if you want to have a single proof that's just a bit longer to generate on the phone. Um, so we have to have all that registry kind of like similar thing that we're doing on EVM but on Aztec but it's going to be easier than EVM because it's more optimized for the kind of things we want to do and uh what else would be on our road map. We have some exciting cool ideas of product we want to build. Um that's also something we have on our road map. That's still things people may want to use like things notary lawyers or like compliance officers will want to use and things real things we can build with Zikas like setting an example of um

real products. So in that same vein maybe for for like some of the the examples of cool things you'd want to see built. Um what are some simple examples you can think of that you could build with the SDK? um doesn't even necessarily have to be with uh related to like onchain verification. It could be also just basic examples leveraging some of the things that you showcased in this demo um like that's on the screen now or um if you have any ideas of cool things you'd want to see with onchain verification that would also be good to to hear your thoughts. So in term of onchain verification like a pretty important use case I can think of is like uh nationality verification if you want to essentially prove that

you're not from a given country because sometimes you have like cension countries or you have like country which are uh not always good to interact with uh such as North Korea for example. So you you may want to use that to build like for example um region restricted air drops because you know you some jurisdiction where it's not people should not use it so you restrict to those to the region that are allowed um or as for age verification which is a pretty important use case offchain um onchain I'm like still trying to figure it out but you could have restrict access to gambling plat platforms to over

directly on your smart contracts. So that way those kind of products that are generally meant or over 18 to adults can also be restricted on chain to only adult and not childrens. Um we we you remember like that was that was nearly a year ago that was when Zik passport didn't have all this tooling and that was very early on. So we had like a very makeshift implementation but we built that fun little project called coin hub that was um around age verification that was um a play on words um for website with a similar name but with one letter difference. So the um for that kind of industry there are also use cases uh for

the adult adult content industry but as for onchain maybe I've heard of some project of like um web three only fan but I don't know how that's going but I'm not the kind of thing I would use but if you can think of something like this where you would need to restrict age um on train then it might be useful as well for that in Uh continuing that thread, maybe uh you could talk about like um just how to think about proof generation time and then like what are maybe some common mistakes that developers should try to avoid? Um I think like proof generation time comes to mind maybe uh as something that should generally be thought about with

noir proofs, but what are some things that like in using this SDK are important for developers to consider to ensure that they build like a a clean like UX and like an actually usable app? So in terms of proof um generation time, so the more information you're going to request, the more it's going to time it's going to take. So the way ZK pass works is that you're going to have different proof generated depending on the kind of information you request. So for example here you have three proofs generated. The reason why is that this is one proof the disclose those two request. If you only add this this would be one proof because

this is generate this is disclosed by one proof. The disclosed proof is a single proof but then you have like a proof for like inclusion and you have a proof for comparison of age. So you have three proofs. The more proofs you you ask for, the most more data you ask for, the more proof it generates, the more time it will take. Now for um for the fast mode, which is why it's called fast, it generally is not going to take more than 10 seconds even if you ask a lot of groups to generate. But this is something that's only optimized mostly for offchain use cases. So with this, you can have like pretty good UX uh easily because it's pretty fast. uh but you're not going to be able to do onchain. Now, if you switch to the compressed mode, that's where things

gets a little bit tricky because this is much longer. It's still to be optimized. But I um I would say that right now with the current instance of the cloud prover we have running in order to generate that recursive proof. um this probably going to take a minute or two to generate compared to a few dozens of seconds with the fast mode. So this is why this fast versus compressed. Um and it's even so even more going to be the case if you ask too many information because if you ask like if you have like um those sub proofs if you have like seven or eight subroofs to recursively verify then you're going to

be probably more three or four minutes. So that's a bit challenging in term of UX uh for now for the onchain use cases. Um we'll see how how to improve that but um we're kind of severely limited by the recursion uh number of constraints in in Baratenburg. Um as for the other use the other issue now with um I would say onion verification is also the solidity smart contract is not quite gas optimized just yet but now it's on simply so it's fine uh but um both the verification of the proof

and maybe some of the helper function we have may consume quite a lot of gas although for now most of the actual cost is from the verification of the proof so that might is something that will be improved later. Um but that's just a gas issue more than um a time. Although if you have like a very expensive transaction, it may take more time in the mele to be confirmed. We have uh uh one more question. It's related to another one. So someone is clarifying one that I had asked for more clarification on. Um and then I think it's the same person who's anonymous who's asking uh like kind of restating that question. Oh, let me check.

Um, oh wait, there's two function. There's two questions actually. Um, okay. Um, the mobile app is installed. The data is lost. I log number 18. If I delete the app, does my phone reate the proof? Would it map on my previous existing identifier? Yes, it would because it's only depending on the ID and not the app itself. So yeah, if the app is uninstalled and you scan the ID again, it's going to be the same identifier still. Now we thinking about whether we should do registration

or not uh with a secret, but that makes things a bit trickier for re-registration. the the um the idea of like registering with a secret comes from the fact that the unique identifier is only dependent on the ID. So technically the issuing country would be able to track people because they are aware of the data that they issued. But apart from that that's the main threat or anyone with your passport data but you shouldn't give your passport data to anyone. um what happened when you scan the passport then install and install the app again that's I think that's kind of related or is that pointing towards something different that's the same uh

person who asked that so basically like Nicholas was clarifying a question I think the same person yeah I think they just asked again they also asked an honestly previously yeah and actually let me show let me show it in five. I'm going to so I have two IDs on my phone and I can show that the unique identifier will be different. So I'm going to switch. So here I'm using my national ID. So you have this one started with 50 57 and I switch to my passport.

It's going to be a different one like 174. And I mean if I generate it again with my passport, it will be the same again. Y there's no idea. One ID, one identifier. Nice. Awesome. Cool. Well, I think um unless there's any other uh final questions, uh we can wrap up. Thank you, Theo. Uh this was super cool. Um and I mentioned in the Discord if you have any questions specifically about ZK Passport, just mention ZK Passport explicitly and then tag me. Uh and then also tag Theo. Um and then we will do our best to try to

answer any questions about uh ZK Passport stuff. And just in general, uh if you have any questions about the program, feel free to tag me and I'm happy to answer. Cool. Awesome. Thanks, Dio. This was great. Cool. Bye, everyone. Have a good one. Hey, everyone. Thanks for the time.