ZKPassport: Private Identity Verification

Transcript

[Applause] [Music] All right. So, yeah, I think now is good a time as any to kick this off. >> So, I'm Michael, um, co-founder of Zig Passport. Co-founder, Theo. >> Theo, you're here. >> And welcome to the workshop. So, just a high level of what we're going to go through. Um, I'll kind of explain what's possible with with e passport and zk passport, what it allows you to prove, some interesting use cases. Um, and then we can jump into our SDK, which is going to be it's going to be like a hands-on workshop um, with a really easy flow of of basically plugging in ZK Passport and you'll see how you can actually use it

right now in the real world to be able to have tap into these identity primitives and prove really interesting stuff and get these really cool properties. All right. So, >> diving in. Um, I'm not sure who's familiar uh with the passport here, so I may as well just um yeah, I can Yeah, I can give an overview of the flow here and how it works. Um, so high level governments around the world, they um they basically have these root certificates that we we get from official sources in registry and these root country certificates. They when a government will issue passports for their citizens um they will use these to sign over the data in the passport. So everyone's passport you have a anc chip

on it and we our app allows you to scan that data into the zika passport app and then we utilize Zika circuits with noir to essentially uh prove those signatures are valid um through the root certificate to the intermediate certificate to the passport data itself. Um, and this uses the Bratenburg backend proving system as they also made um, and it's very efficient um, with snarks and that allows us to have mobile proving which is the key part here for privacy. So other proving systems um, they they're way more memory um, intensive and we need to minimize that when we're doing these proofs. So we have these four different subroofs that we generate. Each subroof is responsible

for a different part of the the verification process along the route and then it's all client side. So you the privacy is is intact there and none of this sensitive data leaves the device. And then you can have this final proof at the end um that allows you to have selected disclosure over um for example like you want to maybe just prove which country you're from. You want to prove maybe something even as granular as your first name. Um it could be the over a certain age, over 18, over 21, even between an age range. All these different possible options you can do. And with this SDK, you can essentially request that via the TypeScript um interface when you you use the library.

Um and then the it generates a QR code that you can display to the user. They'll scan that QR code and then it'll basically route them through to the um download the app if they haven't or it'll open the app with a request prompt. Um so yeah, we can go through that that process and this is kind of what it looks like. Um this little video recording here of the flow. So, you'll scan this MRZ region first on the passport. You might have been familiar with this. There's two um bottom lines or three lines for a national ID. It'll use the phone's NFC reader. It'll scan it in. The passport data loads up. So, you get to see a picture of yourself here. Then, you'll scan a QR code like this. Um it'll request the credentials here. So, this is like proven over 18.

You'll accept it. It's kind of going through really quickly here, but if you're watching the recording, you can probably pause and slow it down. Um and then yeah the proof is then sent over this end to end encrypted bridge to a websocket bridge to the the front end um of the service where they can pro they can verify that proof on the back end for web two use cases. So recently we integrated with um with well devcon last year but dev connect this year to provide ticket discounts um if you can prove that you're from sort of Southeast Asia or or Latin America the recent DevCon get dev connect and you get a a 50% ticket discount. It's really wonderful seeing these integrations. Um and more recently we've integrated with um Aztec the sequences u so basically as a way to mitigate the the sort of um

airdrop farming where people spin up you know hundreds of nodes and essentially to to maximize that you know the air drops they can get flooding the network. This uh requires zika passport proof that's completely private. Nothing else is revealed except for this unique identifier that emerges the proof. Um, so that's kind of like the minimal proof that you can actually generate and that provides the super resistance to um, have it. So it's like, you know, pretty much one person, one sequencer. Obviously, you might have two or three passports, but you're not going to have a hundred. There's a really strong resistance yet.

>> Yeah. >> So it works both with national IDs and passport. Um, I think for example, you have a national ID here. It's like a French one. So that works too. And I think someone in the crowd just tried with their national ID as well. >> How was the experience? Good. >> Oh, that's a great idea. >> Where's that one from? Which country? >> Germany. >> Oh, Germany. Nice. >> Oh, >> first time using second passport. >> It's the first time I use a digital function of the passport. >> Ah, >> I always thought I needed a pin code to use it.

>> Um, you need spin code for some kind of operations, not all of them. Uh, but yeah, it's like >> code for login for example. >> Yeah. cuz like I don't I don't know that any >> some more sensitive data like maybe fingerprints that is embedded. I think it's for like interaction with the private key. >> In the chip you need the pin code obviously. >> No idea. >> Lot of cool features. Yeah. >> And is it is it the same standard across all nations or >> so? Yeah. So if you see this um little icon here >> uh this is the sign that's IAL compliant. So this is a standard set by the international civil avision

organizations which is a subsidiary from the UN and essentially they standardize all passports since the '90s and now the standard is also um done with national ID as well. So like in the EU for example it's been mandated since 2021 to do that for all national IDs. Yeah, if you're curious on the sound, it's I 9303 and it's a massive PDF. Um, like 50 megabytes, something like this. >> Actually, I actually read the entire thing. >> I'm so sorry. >> I skimmed it mostly. >> It took it took me about >> it took me about four days to read it.

So, yeah. Interesting. >> It's not like reading. >> This is probably implemented across all >> mostly mostly. This is the kind of the issue where this is what we're currently uh smoothing out all the rough edges by getting people to come and help beta test. Um we can these errors that come up and then we sometimes we'll reach out to the person individually because obviously it's passport data. It's very sensitive. We don't want to just have you kind of analytics that would re reveal that. So it's a pain process of more personalized um you know bug fixing. Uh yeah, it's like um it follows this. Oh yeah, go ahead.

>> Wait, what? >> Wait, what? I thought you said the gender wrong. Okay, >> wait. What do you have? What do you have in your gender? >> Female. >> Wait, you did get it did get the gender wrong. Okay, >> female. Wait, what you have on the on your AMZ? Like what >> on your do you have a M or like do you have a M? >> Because I know there's a gender neutral thing, but I've never seen it before. >> But the thing is I think it doesn't even have a >> This is an interesting edge case. >> There's no gender. Do you mind if I have a quick >> I think it's only in the NFT.

>> Yeah, I think you're right. Yeah. Um >> data. >> It is. >> You don't have gender on your card. Yeah, >> the passport you'll obviously have it visible national ID >> because like blind blindly blindly on display it defaults to uh to female if it doesn't find the right gender. >> I I guess I should create a new >> female zero. I guess >> it's like it just detects if it >> we put the gender first as the default. >> We were using the tenary operator. >> Yeah. Yeah. I'm going to need to train that condition. >> And this is very interesting. So you don't have any gender.

>> How about a question mark if we >> I figure it out. neutral. I'll just remove the field. Yeah. >> A question. I scan my ID and it says connect to website. Yeah. >> And then it says position the QR code inside the frame. At what website does it mean? Like >> so let's say you got to show the demo. >> Yeah. Yeah. U go to the browser. >> I think I already have opened it. Uh some it should be. >> So we have a demo.zip passport. ID up. This is a really nice place to kind of get started just to to see it. >> And then the source code of that is available too. So you can easily spin them up yourself.

>> I have another question. Uh how are outdated documents uh handle? Like if my password is expired >> if there so the current date is passed in as a public input and it'll check it that it's basically um not after that date it'll be invalid. >> So it's the website that requires proof from me. It kind of links it to the current date and I cannot prove anything with my expired password. >> Yeah. Because >> like my date of birth hasn't changed because my password. So essentially the in the circuit we pass the current date and we verify it against the passport date like privately but then the website is also going to verify on their side that that date is like a >> close enough to the current date >> close enough to the current date so it's not getting it to old proof and after

that because you're kind of obliged to have like um a recent proof you kind of have to regenerate it uh regularly and so if your passport expires you can't do any proof anymore and so you >> so isn't the Like I'm just trying to figure out so say my passport says my date of birth and then my passport expired but my date of birth hasn't changed and I can prove that I'm over certain age because this information will not change ever. >> So technically I could prove it with an expired password. >> Yeah but >> I think it's pars um so you wrote that you didn't make it up but the idea is that as it when you make the proof you pass in a date as a public input. So let's say is 19th of June 25. So I pass in truly fired and then from the

passport data the the ZP circuit will check that the expiry date of your passport is ahead of that date. >> So let's say your passport expired January treasury 4. So you could make a better proof where as a public you pass in say like December is week three but then that's that's a visible part of the proof. So you serve it to people well this proof was was made against 2023 and it's 2025. So >> yeah. So, >> not only will they verify the proof, they'll also check like a logic check outside the proof verification that the current date from their system clock is close enough to the input public input date to the to the proof.

>> Because my question is like if I want to check proof of age and I accept also like can I choose to accept expired passers if I want? >> Oh, as an option >> in our current logic we only accept non-expired. >> That's what you're saying. Yeah, we don't have that option, but we can add that in as a flag of like ignore if it expired perhaps maybe within a within a range maybe within the last five years if that's what you're after. >> Yeah, that question that kind is like you measure the certificate authority. >> Is it like similar to the uh API system that exists just to like group websites?

>> It is. Yeah. Is there some like company based in the US or something that issues everything eventually and >> certain countries like do all passports issued by countries like automatically expire? >> So they they call like certificate signing authority. So they each country has their own authority and they are the root source of trust here. So each country is dependent on whatever is like their passport, their national ID, they're the ones signing it. They sell basically have their they issue their own route certificates and then they'll distribute them through diplomatic channels to ICAL the international civil aviation authority who collects them and publishes them online and so we have an oracle that basically uh grabs that registry um and then we publish it this just announced um yesterday we just we just launched this registry explorer at

registry.zipasport.id. So this provides user visibility um you know transparency into what it means to be a valid proof and so you can browse through all the different certificates in the system. So you can see here there's a 49 rich certificates of all the countries you can filter by the signing algorithm signature hash algorithms um or country >> passport gen so they allowed to use RSA CDSA and within that they can do whatever they want. >> So >> and this this also hooks into these um certificate routes. This is one of the public inputs and this is the like the root of trust essentially. Um and this this hash will represent the merkelized uh country certificates. So you can also view historically here what that meant at that time. Um you know also published on IPFS kind of striving to be as

decentralized as possible and uh >> create those roots. >> Yes. Yeah. Yeah. Yeah. Um so yeah this is basically just a JSON uh file here with all the different public keys for the RSA ECDSA and the different parameters of each and this is what gets pulled in um and Merkelized when you want to create like a proof essentially the conclusion that you're in here. >> So essentially when you scan your passport uh we get the what we call the intermediary certificate which is directly on the chip that directly sign your passport data and that was signed by that those root certificates. So we ping that the registry and we fetch the certificate that corresponds to your passport intermediary certificate. So we can verify the whole chain. Here's how the demo looks. I'll just do a quick run through of the demo. This is my

Australian passport. Load it in. I'll go um you know could be anything here. Proof of name. Um QR code comes up. I'll scan this. This is an end to end encrypted websocket bridge. Um >> in there did you scan it before? It wasn't recognized. >> Okay. >> So, this is me. This is this is me during the demo. Um yeah, on my phone. And then I'll I'll um I'll press confirm. It'll prompt me on my device. Confirm. It'll generate the proof locally. It's going to be a lot faster this time because the first three sub proofs are cached. Um the the last sub proof is this discloser.

Um and that's the one that actually like it's like a pivot proof. discloses for example um just my just my name that's sent back over the websocket bridge where it's then verified either just in the browser here it could be sent to to a backend server or um for you know KY ZK KYC or it could even be onchain so we have a a cloud prover that takes those four subroofs and then recurses them to a single EVM proof that you can use on a chain somewhere >> yeah so when you scan your when you scan your national ID when you scan your passport one thing you didn't realize that the proof were generated straight away those are the base proof we mentioned so they verify your signature and the integrity of your data. This is done in the background. So you only need to generate those once and then every

time you do those kind of like verification we generate the final proof that disclose whatever data is asked. >> So it's really nice the UX wise it's a very instant kind of >> it's only going to take like one or two seconds like tops to generate uh unless you have a lot of information required but >> yeah so now that you've seen what TK passport is and how it looks and how it works I think it's a good opportunity good time for us to dive into how to build this Yeah. And so that's where the SDK enters into the fold. So integrating ZK Passport is pretty easy if you're a web developer, especially with the vibe coding now. It literally probably within minutes. Yeah, you need to uh to to activate Max on your cursor if you didn't. I've tried it. It actually

navigates to the docs and figures it out and then we'll um utilize the SDK in the right way, which is impressive. This is claw set for Max. And so this is an example of our SDK. So it's made to be as simple as possible and abstract as much of the complexity that behind all that and it's meant to be used both in a web two environment like regular flow fully offchain no onchain stuff all as well onchain. So we provide both option both flows. This is an example of a purely offchain flows.

you set up ZK password with your domain name that identifies that the verification is tied to that given domain, it will it will actually change the unique identifier uh associated to your passport or a national ID because essentially this unique identifier is scoped to your domain name and to the custom scope provided here. You don't have to provide this one but you can provide it. So you can like kind of like create categories and that will change the unique identifier. So this way from website to website you will not have the same unique identifier.

So it cannot try to track between different website but you will have the same for the same website and this subscope here you can imagine this to be a subscope. If you wanted to have polls for example you'd have a different identify a different ID for poll a different poll so that you can't link between the two um interactions. >> And so once you've configured zik passport on the on this line you can start to build your request. So you provide the name of your service, the logo, so you have like a nice logo that shows up on the access request page on on the app uh and a purpose so you can explain a bit more to the users that also shows in the app what you want to do with that data because they have the final say they can reject your request.

So you need to explain a little bit what you're doing with that why you're requesting this data and then once you have done this you can use that to build your query. example here is like uh a proof of age greater than or equal to 18 and you can kind of like build your query you can chain different queries comparison of age uh comparison of nationality u of issuing country design here with the with the training. So for example, instead of going dot done, you could go um dot, you know, in and then you could have a list of countries.

>> If I if I if I show an example um in the docs, if I can find it I it's open somewhere actually. Let me just go here. >> Example of chaining and that quick start get started basic usage here. You're going to have an example here. You chain multiple conditions. You want to disclose the first name. You want to check the age is greater than or equal to 18. You want to check that he is an a EU citizen. So we provide some constant for clarity for for ease of use. And as well that is not from Sweden >> Scandinavia in this case Scandinavian. I didn't put Norway because Norway is not part of the EU. So there's no need to

check for that. >> Um so that would be an example. It's made to be as simple as possible and very simple interface. >> Will that do one group? will all do it in one group. >> So you have like um so we have this idea of subproof the me Michael mentioned we have different modes. So the the basic mode is what we call the fast mode. That's a default one. It will uh reply with all the subroofs and it's much faster. It's like a pretty good for web toflow because you you find verifying like multiple subroofs in the background because it's faster. Um if you want to verify onchain we have this compress mode which actually recursively verify everything into a single proof. So this

takes a bit more time because the recursion is a bit more expensive but you do get one proof that you can verify and chain instead of like multiple subproofs >> to fix that because we have cheap recursion crypto but it's not exclusion like ultimately like if we do if we get to like improve the performance gets to get improved you can remove that fast mode and like be like single proof for everyone even on web two flow but for now we like separated it because like the difference of like speed is like quite consequences and >> this is ultra Zach that would work for ultra like EVM.

>> I think all this um it's just it's just shi sensible and sorry is a bit weak but but if you use that forg then the final proof is actually easy to verify chain being so do one layer pressure. So it's not but we want to make it easier for sure. >> Cool. Sounds great. So you can see an example here's like a web this is the web toflow you would get uh from the query you would you call done at the end so it finalized the query and you get the URL and other callbacks so the URL you can use it to encode into a QR code or you can directly put a button that would open the app if it's directly on

mobile so it would like instead of like you won't scan a QR code if you're already on your mobile phone and once you have this you can also use the different call backs so on request receive will tell you when the user actually scanned the QR code. So they received the request. So you can actually update your UI in consequence to what the user is doing. >> So before you saw when the QR code was scanned, it immediately detected that and showed like the the prompt user. Yeah. That's how essentially we updated the flow of the demo using those callbacks integrates the SDK directly on generating proof. It means the user click on confirm and the proofs are being generated. Uh and then you're going to have the unproof generated which you can actually get the proof if you actually need it. Uh which might be

useful for onchain use cases where you need to get the proof and send it to a smart your smart contract. And then you got the final result call back which gives back the unique identifier associated to that proof. So that's ID the verify boolean because behind the SDK verifies everything for you. It verifies the proof. It verifies all the public inputs and the commitments. You don't have to worry about this. This this verifier will tell you whether all the checks went through. >> This happening this is happening um on the in the browser on the front end. So you wouldn't necessarily rely on this as a guarantee, but you could send it on to a backend API for example and you could verify it there as well.

>> Yeah. So like you would like this is full like this would be an example of like the interaction you would do on the on the client side but you do want to use uh the unproof generated callback to be able to get that proof along with the result to send it to a server if you want to verify this in a purely web to flow >> or or on chain which obviously would verify verifier >> like we have an example here where you would do that same process and then you would have a server side where you kind of pass in the quer result and the proofs and then you verify it with the ZK passport SDK on the on the server side and that way you can do whatever logic you want. For example, update your database, use the unique identifier as a

way to identify user specifically. For Devcon, what we did here was we have a database of uh voucher codes and then we send that it gets verified. the unique identifier essentially allocates a voucher and so then if they come back and try it again it'll see they've already been issued a voucher and it'll issue the same voucher again. So that provides like one ticket per passport. >> Yeah, >> I guess in a web two context is it really necessary to store the proof itself or is it that >> this person like in a web two context you're mostly going to want to use the unic identifier and whenever like data has been disclosed storing the proof is not that important. You just want to verify it before you do any kind of >> before you discard it at least verify the proof >> on the back end and then you can discard

it. >> The reason why you want to do it on server is like whatever logic happens on the client can be faked. So you can never trust fully like a purely client side logic verification. You need to do some server or like onchain. The proof's quite small. So it wouldn't be an issue just to persist it I think. Yeah. >> Let's say I have to be compliant. I have to prove that I verified exactly the KYC kind of thing store or what would I do >> the proof itself >> that's irrefutable if he's come and I can show them the proof and they will >> exactly >> well we yeah we will they so >> that's up to the government regulators precedence for this >> we're going to build some kind of tools that can be used for compliance officers and authorities so they have like a more

better UI instead of like seeing like a bunch of like hexodimal strings >> cuz that's not going to be good for them but like we're going to provide those kind of tools to for auditing uh by regulators. Could you elaborate like what does it mean that the verification can be tempered with by the user like assuming that the user cannot fake a password >> what can I do client side >> it's like just client side any logic you run on the front end uh you can cheat it because let's say I ver the SDK verifies the proof and everything but then the >> verified equals true you could just put that >> it would just it would just because it's a code that's running on the brow all the calls going on the browser the client >> proof is cryptographically sound >> yeah it is but just like I'm I'm not

talking about the proof. I'm not talking about all the logic that you build on the client side. >> Like if you just sent the result of verified to a backend API. >> They could just change that to like verified that. >> So you need to send the whole proof to a trusted back end where you then verify the proof. The proof itself is >> that's logical. I mean >> of course clients like we assume the clients can temper with the UI basically but they cannot >> that's all it is. Yeah. I thought I just they cannot temper with the proof. They can only temper whatever logic you build on your front end. I mean otherwise it's just the client says it's verified. We trust it's verified. We could just throw away all the crypto magic. I just trust what the buyers.

>> Exactly. Yeah. >> Would how would I test this? Can I order a bunch of dummy ID cards from different countries and >> oh uh we have a feature called dev mode >> and sorry. Yeah, we have a feature called dev mode. So if you uh because some people may not have like functional IDs or they may want to test different kind of data. So if you hold at the bottom you will get like a little popup and you can enable the dev mode. So this is like uh you have six different ids if different mock password >> like mock characters >> uh with different data different birth date different document number and all issued by the zero knowledge republic which is uh our >> yeah so we had this country just on test

net called ZKR or the zero knowledge republic and just to clarify here um the unique identifier is always zero for the for this country. So it's impossible to generate you can generate valid proofs but that would always have a nullifier or unique identifier of zero. >> Uh this been set to one recently. >> Sorry to one. >> Yeah it used to be zero but we set to one because it's easier to test on chain because generally what you're going to do on chain with like smart contracts is that you're going to register with the proof and you're going to want to check that that address has already been registered >> like a mapping default value is zeroity. So it's kind of tricky to test with zero. So we just change that to one which is easier now. Um so we actually the example for onchain verification

here you we have an entire example and you see here the mode is like set to compressed EVM. So this is like compressed proof. So single proof that's been optimized for EVM verification. We have another mode compressed which is also single proof but not optimized for EVM verification because you know EVM has a specific pre-ompiles uh that you can use that are optimized. So that's why you need to change a few stuff. >> Yeah. Yeah specific >> huh >> is it chain specific? And >> but it says EVM chain. So all you >> So this is optimized for EVM in the sense that um so the cryptography behind uh for Baratenberg they use PYidon 2 >> uh which is well optimized for Zika

system for Zik proving system but not for EVM verification like 2 is quite expensive to do on an on EVM contract. So instead when this is like a different type of proof still barenburg proof but that's optimized for EVM by essentially replacing Poseidon 2 by Kak or Kjak 256 >> I think the question is that is it chain specific if I generate a proof for Ethereum SQL here >> uh yeah so so you will here essentially when you do this um we currently only have a deployment on sepoleia >> but we we can deploy to any EVM capacity >> for now we only have sepia but like EVM chain you specify here, it's actually going to change the um the

unique identifier because the scope is bound to your domain and also the chain ID as well. >> So you can use that proof only on that given chain because this the smart contract verifier will check that as well to prevent >> clearly. >> Yeah. Exactly. Exactly. It can't be replayed. Yeah. Um so oh and so we have we have this specific function for like which is pretty useful in the context of onchain verification which allows you to bind a user address like Ethereum address to the proof this way some because if you can't if you wouldn't bind it what would happen is that you send your proof and then someone will just take it from the meool and like use your proof and then you

>> your proof is my proof >> my proof won't run you essentially. So for example, the recent um like super resistance protection for the sequences with Aztec, they needed a way to bind it to um to an address um and this was the way that that's done. >> Does binding require uh proving that they own the address like signing something that address you'd verify that the message sender is whoever you bind it to. >> Well, that could be a way to you any integration you wanted at that point. Yeah. You would have your own solidity contract that you'd use and then verify the logic and then you'd call out to our verify contract which would return true.

>> Yeah, you can also bind it to custom data as well. So this is this is like interpreted as a string in the context of custom data. Just know that you have the the SDK will check that for you. But you have up to 500 bytes >> of free space to use. >> It's quite generous. >> It's quite generous. So we didn't want to push it too far in context. You got to uh the more you bytes you have the more expensive the proof is to generate. >> You could use your password as a hardware >> as a what? >> As a hardware wallet. >> As a hardware wallet. Um >> it is signing whatever you're inviting to or >> No, it's not. It's not signing. It's um the some passports do support this technology called active authentication.

>> But this is a different um thing. This is um if you wanted to have it locked to your account and not have someone in the meool kind of steal that proof and and then use it for their purposes. >> So it's binding on the device, not on the >> it's binding it in an onchain context where you want to have it sent to a smart contract and use for your account. >> Yeah. Yeah. But like the like if my phone gets hacked the binding someone else can >> actually that's a great great question. Um we have another feature coming out um down the road which you're excited about. essentially, you know, currently it proves that you got a valid passport um which is great, but it doesn't prove that you're the person on the passport.

So, we have this feature where it's basically like an encrypted face match. You can do um like a face scan like this. It'll all be local on device. Um it'll generate a face fingerprint and livveness check from that um and then from that face fingerprint, it'll compare it against a face fingerprint vector from your passport photo. And um if they're close enough um then you can basically compare prove that you're the same person on the passport at the time um in zero knowledge. Uh and then we have an MP basically have like a mobile TE assumption there um for the the genuine device. Um >> yeah like the um some people may have wanted to try SDKML for this but this is not necessary because you're already lowering your assumption your trust assumption to the physical hardware because you need the device to be taking

the video feed. So you need to trust that. So there's no point on trying to add in ZKML here. So >> if you wanted if you had a higher security use case um where you needed that kind of guarantee then you could just for example one of the flags we'll add is this extra strength livveness check um to to ensure it's the person um that's scanning it at the time and and doing the proof. >> Josh the custom data binding is that just a public input to the circuit? >> Uh so it's a what we call a committed input. So it's like um our own kind of public input. So like we um say it's a public input in some sense. We call it like a parameter commitment where it's essentially um there's a h a public hash over arbitrary data. So you can outside

of this now check that yourself and have as much data as you want and it doesn't change the interface to the proof of the circuit. Now we wanted >> hiding because it's a it's a hash >> hiding. Um it can be you don't have to reveal it but you you want maybe you'd want to um verify that the integrity holds. >> So essentially it's like allows us to have a universal interface for all the disclosure proofs. So they have all the same public parameters. So that way whatever kind of information that's requested we have the same interface. So we can easily plug it into the recursion uh circuit that the circuit that recursively verify everything and the mobile app will actually pass along separately the committed inputs as if they were public inputs and then you can use those committed inputs to recalculate the parameter commitments

and check they're correct and you can do that on chain like the onchain verifier does that verification as well which is also why we have different kind of parameter commitment for AVM and nonvm because we use poseidon 2 for nonVM and we use shadow 56 for VM. Uh so yeah, >> this might be like ahead of it, but uh like from a UI perspective, bro, like is there any way I can integrate this into my own login close instead of like kicking them through an app or the external website, but I like a widget or part of the whole process?

>> Not currently, but would this be a mobile app that you'd be creating? >> Yeah. So we'd have a flow where you'd be able to easily open the ziga passport app and then it would be return to the previous app. So the UX would be much nicer still um rather than requiring the user to do it and maybe even like um you know a way that a message that you can pass along let's say it says return to app X. >> Yeah it's a logo and stuff. >> It's pretty funny cuz like you would assume that would be easy to return to the app that was previously open on iOS but it's actually not. >> On the web it's like would you like to install >> um it's a nightmare. Yeah. Yeah. Yeah, >> open app.

>> They haven't solved that yet for some reason. >> Yeah, just like go see the Apple store. So yes, definitely use >> we'll do our best to refine that though. >> Holy words. So what's what's data is reading in order to understand your passport. There is a standard order >> the for the passport. Yeah. >> Yes. There's a the standard set by the a which is like the international civil aviation organization. So they regulate aviation and because they regular aviation, they regular travel. So you need to wait to identify yourself. So they ended up regulating passport and then they regulated as well electronic passport. So essentially they said the standard for the physic basic physical layout there's some flexibility and the chip and what data it has on it and what signature algorithm it must use what

hashing algorithm it must use. So for example, it has to use RSA or CDSA. It cannot use EDS, EDDDSA, it can only use initial sector. It has to use those and it can only use the SHATU, shadow family or SHA one family of hashing algorithm >> and um >> these are collectively called EMRTDs or electronic machine readable travel documents. >> So e passport national ID. >> It was deployed originally in the '90s. Malaysia was the first country that ever introduced it and then expanding throughout the world. Like nowadays most passport are electronic. For example, if you take the EU, every single passport issue in the EU is electronic. All passport circulation in the UI electronics because they've been like electronic since 2008. Uh the US as

well. Uh now it's more a matter of like actually how many people have a passport. Uh national idea start to follow that standard especially in the EU but you also got some countries South America and even Africa that follows this same standard as well. So it's pretty international. Uh for once you have like some kind of international agreement on something um which is cool. Um so um if I go forward a bit more with the uh on trade verifier flow is that you would get this function get solidity verifier details. So you would the SDK will give you directly the address of the verifier for the chain you're looking for the function name you need to call for verify the proof and the AI.

So you can pass that then to uh for example VH or um EtherJS if anyone's still using that. Um no I'm not fine just fine. Um so and here for example you would get the proof from unproof generated and then you can use that function to get the parameters. So it will par it will structure all the parameters for you. So you only had to pass it the proof the scope you used and whether you want to use dev mode. So like the ZKR passport I've shown you, you need to activate the dev mode on the SDK if you want to verify it because by default the SDK will refuse this proof because it's like if it's used in production it should not use like uh the ZKR proof as a valid proofs and so from

this you get the verifier params which you can directly pass to um VH for like the parameters of the function. So for example let's go to that's the smart contracts. I'm going to skip to that. Uh here you would have example you pass the address of the contracts EBI. Uh the function here's like a specially function register with the verifier params. Like for example, I'm going to go back to register. So like this is a simple example. You would use like a registration flow. So you would use like the parameters of the verifier. You call on ZK passport verifier. You verify the proofs with the parameters, the parameters returned by the SDK and then that responds with whether it's a valid

proof and the unique identifier. So you just make sure that's verified correctly. And then you can verify the scope as well, the domain name and your custom scope if you provided any. And then you can use some helper functions to get the different like um conditions you wanted to check. For example, here you can check your age proof and get back the mean age, max age and current date and you can check everything and you got a bunch like the bind proof here for example. That's how you would do the check. So you require that the user address you get from the bind bound data is equal to the message sender and that way no one can steal your proof.

>> Yeah, which is nice. >> Just to clarify maybe stupid question. So this all is happening on chain. >> Yeah. So this >> smart contract. So if I verify my age, I send a trans. So basically I can implement a DEX that only accepts users who are older than >> 18 or whose first name starts with an 11. >> Exactly. If you wish. >> So no like server required and the user can look at the code of the smart contract and be sure that if I fulfill the requirements then definitely my transaction will be broken.

>> Precisely. uh yeah compliance and maybe like um not from a sanctioned country kind of check on a dex would be a more suitable use case of that and you can even obscure well yeah you wouldn't even reveal your country just that you're not from these countries >> and this verifier contract is it like we need a separate verifier contract for each application or is it like one verifier contract that is >> there one for each chain like it's going to be the same interface for for each chain >> and this hooks into the root registry where the um the certificate route and the circuit route live so it's always check against valid certificates and valid circuits.

>> So essentially that that verifier um will like communicate with the uh registries to kind of take care of all the logic. So you only need to care about specific function and to for your application >> is like the verifi like the kind of root verifier contract is maintained by you still or is it totally like can it be the case if I want to implement my decks with some like requirements I rely on your verifier contract but then you as potentially administrators of the contract can uh shut me off. >> So uh no we it's all open source if you wanted to like do that you could do that. Um the benefit of using this is that we have we we const we update and maintain the registries and what because they may change they are changing

constantly. Yeah. >> So the registers like the registries are also on chain. >> Yes. Yeah. Yes. >> Update them like manually. >> We have an oracle running um currently. Uh the idea is to make the harden that get other people involved in in attesting to that the master lists that are retrieved they are also signed by ICAL. So there there's we're minimizing the trust assumptions basically as much as possible. And then even at some point we can have like um a te guarantee from that as well. And but also you can actually go out and independently verify these and check they are like you can you can replay what what our oracle does and you can see clearly for yourself that they are from the official government sources.

>> Oh so you can verify from the outside of the contract itself. >> Um well it would be there's a lot of steps involved in getting it. Yeah. Maybe a proof at some point would make sense for that but there's a lot of steps involved. Yeah, you can ask >> then you can almost have like a permissionless registry, right? Where you just have a proof anyone can submit the proof of the of the new um certificates. Yeah. >> Can user force add the force updated certificates? >> No, but unless you crack cryptography which quantum I mean quantum computers may be doing at some point like ZK feature that they could allow the users to force update the DK registry if it's not updated.

>> Oh yeah. Yeah. So like a permissionless way to do it. Not currently but that could be a thing we add. Yeah, >> currently you could verify that what we're saying what our Oracle says is correct. Yeah. >> What's the time? >> Um it runs just once once a day. Um and the we we've noticed there have been updates maybe every few days and then maybe there's like you know a period of of three weeks where none of the registry has changed and then you know the upstream. Yeah. >> Yeah. What if I lose my ID and get a new one and I cannot access my wallet? >> Um so >> yeah like I I guess that's per country, right? How fast you get to make the new route. You make the new route every day.

>> So, this is more about the actual root certificates, do the signing of valid of valid passports, but we don't have revocation um built in, if that's what you mean. >> Oh. Oh, so my last lost passport. Yeah, the revocation lists they're um they're handed by like inter >> if you're talking about the registration flow on chain is that I don't know if I put the example here but like the way you would go about it is that you register with a proof and then address. So that address is tied to your unique identifier and if you lose it you can always register without having a proof you're just using your address as a proof.

>> Oh that's true. Yeah because if you still hold the access to the address you could use that to revoke. >> So you you you we know that you already verify your address is linked to that passport. So you can just dregister with your address without having a passport and then you would re-register within your passport. >> This is like application specific logic that you you would add in. >> Um uh I I tried with the Argentinian passport and works. I tried with the Uruguayan passport because I >> ah and it's not working. >> I I understand I don't understand why >> the gray one.

>> I think let me check real quick. But I I'm not sure we have Uruguan certificates. Let me just check. >> You don't have >> Oh, we do actually. Uh we only have we have one from 2015. No, we'd love to after this we can have a look at it if you like and figure it out. >> Zoom card doesn't work. >> It didn't >> because I have the >> I think >> what what error do you get? I think the issue with the passports is it's sensitive data. So it's hard to kind of like diagnose it like publicly or anything like this. We want to have we'd like look at it privately to check whatever the fields are.

>> My name is weird. >> Oh, I I think I understand the issue. Yeah. Y >> just weird in general. >> Able to verify. So names are accepted. >> So my real name is Jim. >> Okay, cool. >> And it shows up as J. >> Fala. What? Wait, could you try? >> This is an interesting one. So, this is >> a very edge case. >> I I know the I think I know the issue why, but we'd love to chat later. We could have on the Thanks for the edge case. That's great. >> Oh, that's my last >> the base proofs again.

This means that the commitments were not equal between the proofs, which is weird. >> With a space, >> okay, >> plus the UI think my name is Jim Technology, so nothing is weird. Okay, >> we'll um we'll definitely debug that. Yeah, thanks Jim. We'll check it out. Thanks, Jim. Jim, >> I'm sure it doesn't go too >> um I'm not sure like um we have like we still are going through like a lot of bugs because like there's some unexpected formatting. Some are harder to debug because obviously they depend on the passport data which we don't have access to and for privacy reason we can't get them. Uh, so,

>> oh no. Uh, >> I just noticed it's using the brain pool curve. We spoke about this recently. Maybe it would work. >> You said last week there was an issue with your like uppercase brain pool. Oh, >> if you tried it before you fixed that bug now. >> Yes, we had an issue with the brain one uh with the mapping. So, that's been fixed like I think that was two weeks ago. I'm not sure. >> Before. >> Yeah. So there >> taking a little while like you probably have like the biggest one cuz like the German ID card they use the our biggest circuit.

>> It's done. >> Oh yeah. Enable to verify age. We need like a bounty for um helping to smash these bugs. The biggest bug gets the best next to bouncy >> something like >> we have to discuss it. We haven't it might be an idea to get you know. Yeah, this is a pretty big bug. >> Yeah, it wasn't it wasn't able to verify the proofs. That's why >> passwords are still not supported. >> Oh, um they would be supported. Yeah, we haven't encountered many in the wild because they're not as popular.

>> Many of them don't actually have the NFC chip. But as soon as India starts mincing more of those with the NFC capability, it would work. >> Yeah, we'll need to debug this. >> We have the certificates here. >> Yeah, the commitment should be the same. But like now they're not the same. countries have different standards. It's not universal standard, right? >> No, this is universal. This is defined by >> IAL. Oh, you have an idea. >> It's like this international civil aviation authority. They make the standards and they also collect the certificates of all the countries. Yeah. >> I mean, yeah. So, we have one Indian.

>> So, you go into um your um settings and like send some metadata. >> If you ever if you encounter an Indian passport with NSC, we'd love to hear about it. issued out to users. >> I I heard about this recently. Yeah. >> Info. So this would be the info >> with 1 billion people. It's very expensive, right? So >> nothing unusual. >> Don't think so. >> Just a matter of time. I think >> that's the metadata. So is anonymous. >> And for now, I think this should be enough. >> So yeah, we'll try to debug this. But >> cuz I know that it works with German passport. We had like a few people being able to work with it.

>> So the the process is surprised. the national ID um contains essentially a key is is used to derive a key for the NFC communication. So you have to have physical access to the passport and that's what the OCR readers do at the airport. You might see they'll read that and they'll be able to use that to communicate through a process called back basic authentication and then that's um that prevents people from skimming and like you know reading your pocket basically. >> how do you but it's still valid because it says 133. Yeah, that's not that's not the the issue is not the expiry date. I think it's something else because like that the issue was regarding the commitments between the proof. Somehow they're not matching which means there's must be an

inconsistence between the the inputs of the two proofs. >> But I'm not sure what it might be almost lunch time. Hey, I think our session is probably coming to a to an end >> already. >> Oh. Um right. >> Roughly speak. Well, if you have more questions, please we're happy to stay longer. Let let me just uh drop uh the zui. We had a few more slides but just some more. So like the docs here if you want to access to it and I think most uh most importantly if you want to try it out really quickly that we got a starter. So this shows you how to um do the web two flow, the web three flow and also how to verify in a serverless function on nextjs because there's a bit of a configuration flow for next for

like severless functions uh which we should be able to >> so um we wrote we wrote um an ultra honk verifier in typescript >> recently um which allows you to basically verify it very quickly um without having to send it without having to require was modules >> because behind the scenes using uh some BBJ JS. So, BaratenbergJS to verify the proofs. But this requires Wom because behind the scenes C++ compared to Wom. But Wom doesn't work very well in a serless function without proper configuration. So, this is the only um annoying thing.

>> TDR, it's going to be better debx faster. Yeah. Yeah. >> So, yeah. Did anybody have any questions? >> No. >> Yeah. I I have a question. see the documentation and it's there's a set you can uh interfer to uh the place on uh my when the verification is initiated and is a question is do you can you can you give me a hints for like have I come into the process of verification the user with NC verification like I devices This is FC.

So I bit back with Java to confr us presented in specific location where he touchc with some some hardware like can you have a hint for >> well the idea would be that you wouldn't want the user wouldn't want to give their passport data over to a particular service. you they'd want to scan it locally on their own device and then generate proofs to provide to that service so that you can have the protection of selective disclosure because if they just scan it with your device you can read all the data which is generally what we're trying you know you wouldn't that's not a good flow for the user so the users own NFC chip on their phone that's you know that's the magic there they can scan it themselves and then you can request any credentials you wanted you generate a QR code they'd

instead scan that QR code that would then contain the information to provide a prompt to the user would you like to share, you know, that you're over 18 and that you're from this country? They'll accept it. The proof sent back to you and then you can verify the proof knowing fully 100% that's a true statement. >> Hope that answers the question. >> Looks like our turn is over. >> Cool. All right. Thanks very much guys for for attending. Appreciate it.