ZPASS: Truly Secure Identity Verification | John Reynolds - Aleo, ZPass

[Music] hey thank you everyone for joining today my name is John Reynolds I am a product manager at Alo and I specifically have focused on building identity uh digital identity products for Alo uh and my background is in computer science and cyber security I also have a master's in software engineering so I kind of span between the product and Engineering realm today I'm going to be talking to you specifically about building the antidote to the identity theft virus um and we're going to be discussing different emerging technologies that can help support making identity verification safer and more secure so to kick things off a startling statistic 86% % of consumers worldwide have been the victim of identity fraud and this problem is continuing to get worse it's approximated that around $50 billion was loss in 2022 as a result of identity fraud and $28 billion of that was related specifically to Identity fraud that was a result of information gathered from a data breach to put that kind of abstract value into perspective in the space exploration uh industry NASA's annual budget is around 25 to$ 28 billion so one year of identity fraud losses equates to two years of space exploration apparently these are the kind of headlines we continue to see some major centralized platform that has fallen victim to a data breach or Cyber attack and user information has been exposed I think everyone here in the audience would be uh would feel confident in saying a situation where either their information may have gotten exposed in some sort of brief or someone they know's information got exposed so at the end of the day we can all really acknowledge that we have a big problem and we can look back as far as the beginning of the internet to recognize that a unified identity layer never existed and so some of these different tech companies and businesses were forced to build their own authentication systems in order to solve for the hard problem which was to be able to identify who they were interacting with on the internet unfortunately as a result of this variety of different custom authentication Solutions we fell into this world where we had a variety of different Patchwork Solutions none of them were perfect and none of them actually worked in all of the different cont exts we needed them to work in so when when we think about this problem the The Next Step naturally is to think about why it hasn't been solved yet and I think there's two interesting paths or directions or angles that you can take on answering this question why haven't we solved the identity problem of the internet the the first one is maybe a little bit more cynical and that's to say that a lot of these platforms and companies their incentives don't align with making identity verification more secure or more private because you see these companies actually benefit benefited immensely from some of the different transparency and visibility that they gained from users having less security or less privacy and as a result they've continued I think to slow down some of these aspects of the development of identity verification because the incentives just haven't been aligned the other angle that you can take is this is a very challenging problem to solve identity exists in a lot of different contexts across the web and depending on the situation where you're presenting personal information there could be a need for higher levels of validation or lower levels of validation so for instance if I want to open a bank account my bank is going to want to know more information about me and they want they're going to want to be able to validate that information about me somehow whereas if I'm starting a account on a social platform there may not be as much restrictions or validation required so we've seen some progress in the identity realm and when we're just talking about login we can think of the example of SSO single sign on and what this has done for us is it's shifted us from this Patchwork of solutions where a variety of different thirdparty systems or companies are building their own authentication systems to a more Federated approach where users can rely on existing systems or existing credentials to authenticate to a particular website or platform or service so you can imagine the situation where you're trying to log on to some service and you use your Google credentials as opposed to that website spinning up their own personal or custom authentication system and while this did help user convenience and it reduces some of the dispersion of user information across the web ultimately if you just look closely you can tell that there's one major flaw here and and that flaw is the consistent dependence on a centralized entity you see even in the Federated situation if you're where you're able to carry your credentials with with you from one Central platform to a variety of other third party systems the dependency is still on the central platform and it continues to allow us to persist in this client server model this client server model is where a server requests some information about the user the user submits that information the server verifies it and stores this information and that is the transactional requirements to go from being an unknown customer or user to being an identified customer with access to a particular service and this model that we see here is what continues to get us into a lot of trouble it's what UL Ely ends up pushing a lot of information into the hands of centralized parties and makes it vulnerable as it sits on a server that is ready for attack a Honeypot essentially zpass which I'm going to be going to into more detail about today is a product that's built on top of Alo it's an identity product that leverages zero knowledge proofs in the blockchain to provide more privacy and security to users so like I mentioned the Three core tenants of zpass are decentralization and the goal of decentralization is to provide users more control over their information and their data we want users to be able to Define how much information they need to share and what context they're able to share that in the next step to enabling a more meaningful identity verification process is privacy we want users to be able to reduce the amount of information that they're forced to share without reducing the amount of validation or verification that comes with that data and then fin finally we want something that's trustless we want platforms and users to feel confident providing their information to particular ZK programs and be able to execute those programs trustless where the system cryptographically is able to prove and provide security and verification guarantees so I think the way to reduce some of the complexities and very clearly show you what our goal is in uh in the development of the product zpass I thought I would go through a few slides showing you visually how you can understand how zkps can change the dynamic and the transactional model of the web from a client server model to aover verifier model leveraging zero knowledge proofs C pass wants to move the dynamic where users are forced to share all of the information that you can see here on this ID card an address a name expiration date of birth we want to reduce this to only requiring users to submit the minimal amount of information that would be required for some criteria that a platform or a service is is requesting so the goal would be to move from a paradigm where the user is presenting all of this this data to reducing down to a situation where the user only has to present their data birth and a step further than this zkps allow us to take the information and reduce it down to the predicate form which is to say instead of actually even having to expose your date of birth you can just show or prove that you're over the age of 21 in this instance the platform and service gets this gets the Crypt graphic guarantees from the zero knowledge proof that this information came from a trusted Authority that this information is valid according to the DAT of birth on the ID card and no other information about the user has to be shared so the user is protected but also the platforms still have certainty and Trust in the results that they're receiving again this is what allows us to shift from the client server model to approver verifier model and that's to say that rather than a user submitting their raw data to a server to be processed and stored the user actually submits a proof to the server and the server verifies that proof and if the proof is verified then access is granted so we move away from the transactional model of giving servers and centralized entities our personal information and shift towards just proving the information that they need to know about this fortunately allows us or enables us to move towards a decentralized structure away from the Federated structure so it's one step closer to giving users full control of their information and we're used to assimilating decentralization directly with the blockchain and Alo is a layer one blockchain but we're also used to assimilating um public or transparent or visible with blockchains and the main difference between Alo and the traditional blockchain is that Alo actually is a private blockchain so the information on Alo is encrypted and using zero knowledge proofs users are able to prove information about themselves or about the information that they possess on chain and no other users can go to an Explorer and see all of the raw data it's completely encrypted and it is also decentralized because it exists on a ledger and so in this scope you can imagine that a user now has the ability to rely on ledger-based technology to support trust but then they also get to leverage zero knowledge proofs to enhance the privacy of the transactions that that are taking place on the blockchain so the way that this works or the way that you can think about this working on Alo is through a series of events you start with a program or a smart contract you can imagine imagine it as that exists on chain a user pulls that information off of the blockchain off of a program registry and they execute that program offchain this is an essential piece to understand here the portion that's providing the privacy and that's enabling the zero knowledge technology to really shine is that the user is able to execute these programs on their local machine or in a secure environment they able to produce a proof from that execution offchain and then the user sends or broadcasts that proof to a validator and a validator node is able to verify the proof and then update the state of the blockchain so as this diagram shows again we have a program and within the program there's different functions or transitions as we call them at Alo these get executed and these update ultimately when finalized on chain the state of the blockchain but first we go through the execution process offchain produce the proof and then the user has the ability to broadcast that to the chain or even verify that proof in an offchain capacity entirely so when we think about zass or this identity product that I've been discussing we start by creating a zass the creation of a zpass or the issuance of the zpass is a process where the data about somebody is created into a a digital credential or a digital ID and then a signature is added over the information for that particular credential zpass also actually supports transitioning any sort of signed ID document into a digital credential one example that you'll see in in the diagram that I show here shortly is using a pass passport for the example so many people might not know this but passports actually have NFC chips in them so they can be scanned by any standard iPhone and each passport has all of the information relevant to the passport and the passport owner existing within this NFC chip it's also all hashed into a Merkel tree and digitally signed and what this means is we could scan a passport we can extract the data elements from the passport we can hash those elements and verify the signature against the publicly available signature of the signing Authority which might be a government or the authorities that the government of a particular Nation have assigned to issue their passports and again these are these are public keys or public addresses that can be collected or that are publicly available so the point that I'm trying to make here is the creation of a zass can be something that's from a net zero starting point or it can be something that exists from a little bit further along the line where we're using existing credentials that are already accepted in real world scenarios such as a passport The Next Step once you have that information and that data into a credential you generate a proof and the generating a proof is the response to some verification so the user has a credential they're answering some verification saying they're over some age or they're from some particular country and a proof about that information is generated and then finally the user has the ability to show that proof they show the proof to a platform the platform verifies the proof and the user is able to progress through the flow so to go into a little bit more detail about the creation process again you can imagine starting with an ID like a passport and this would be going from a passport from a physical credential to a digital representation of that credential on chain so you start with the passport and then in the middle section here you see we have an execution a signature verification would be the first part of the process for this execution and that's to say that the goal here to create a zass or to create a record on chain is to Simply verify that the information from the ID is valid according to the signature and the issuers public key that is relevant to that ID once you verify the signature you can add the attributes of that credential to a record on chain and then you additionally have a proof that tells you this information came from a from a signed credential for this particular issuer and so the proof tells you that it's valid according to the signature and the record possesses the actual data for you to use in a a future Capac capacity to verify some information about yourself so we can assume at this point we now have a zpass credential a record and a proof onchain now the benefit is that users can reuse this in multiple capacities they can use this across a variety of different context and they can scale the amount of information up or down depending on what the service or the platform requires so from this point again it's a similar structure where you have some data element you have an ex ution and then you have a result the zass in the form of the record is presented to an additional program and within this program the execution is responsible for the claim verification so for this we we'll just continue to stick with the over the age of 21 as the example so the zpass has the user's information and it's encrypted but it exists on chain the user presents this record to another execution that checks if their date of birth equates to them being over the age of 21 based on what the current date is also likely it checks that the the passport that's being presented or the record that's being presented is not expired and then finally it provides you the proof as the result and the proof attests to the fact that the user's information met the verification request which is that they're over 21 and they have presented a valid passport or a valid zpass ID and then finally like I've mentioned now a couple of times the proof for it to be verified can be sent to the Alo blockchain in a TR in the form of a transaction where a validator node will receive the proof and that transaction and verify that the proof is valid before they update the state of the blockchain or it can be verified offchain where the user just presents the execution from the blockchain and the platform verifies the proof that the user provides back and maybe they also verify that the US the the ID that the user presented the zass the user presented does in fact exist on chain so they could do a zero knowledge proof an inclusion proof that proves that this particular record was issued onchain and you can do that by checking the global State Route so I'm going to get a little bit more granular with this example uh as we move towards a more code focused version of this explanation um so this is going to be very similar to what I just explained but we're going to go into a little bit more granularity we'll start with the issuance portion and as you can see the idea of the issuance is taking either an existing credential and converting it to a record on chain or it's taking new information and issuing it in this format so that a user can receive this and have a representation of it on chain so to begin with you want to switch from just having issue or public key and then attribute as an example here to actual variables or actual attributes about the user so we'll have we can assume issuer public key owner date of birth nationality expiration and signature now that we have this information the next step if we're actually going to be issuing this credential is we go through the process of converting it into a Merkel tree the reason that we do this is we want to provide the ability for the user to have the most privacy and security while we do support a credential schema approach in instances where it makes more sense or it's more computationally viable um in the example I'm going to be covering today I'm going to be discussing the Merkel tree approach that we use and despite the fact that Alo has a completely encrypted blockchain there are still situations where information might be private or delicate enough that even in an encrypted form you don't want to present the information on chain and so instead of doing that what you can do is you can leverage a Merkel tree and what a Merkel tree does is it separates the attributes out into a set of hashes so you can see on the slide here we have owner date of birth nationality and expiration separated across the top the first step of generating a meracle tree is hashing those first attributes so you create a hash and for those who aren't familiar with hash functions the purpose of a hash is to create a representation of some set of data that can't be converted or decrypted or deciphered back to the original set of data without knowing it and so the difference is for encryption when you encrypt something you have a private key that you can use specifically yourself to decrypt it um a hash is different you you can't go backwards from a hash in the form of a function so it's a one-way function it's just creating a string representation of some information so you hash these different attributes and then the next step is actually combining the hash of these different attributes in the format of a tree so you can see we start with the variety of these hashes then the next step is hashing the combination on each side of the tree and then finally in this example we just have four attributes these converge specifically to a root hash and that root hash is a representation of all of the attributes within the credential and this root hash is what the signature is generated around so if I'm going to some service provider or if I'm going to some uh platform or business and they're going to issue me a credential they'll receive this information about me and then they'll have an automated flow to reduce this down to a root hash and then sign it with their public or with their private key that can then be verified using their public key so in the future everyone is aware Who provided the credential and that none of the information or attributes within the credential have been Disturbed the next really convenient thing about using a Merkel tree approach is that it allows us to selectively choose different attributes to prove during the zero knowledge program portion so without having to actually have any of the information exist on chain outside of the hash version of it what we can do in a zero knowledge program is we can can say for instance we want to prove that a particular date of birth equates to the user being over some age so we can identify the date of birth and in order to prove that we know the date of birth that is on the credential we can create a proof that says or that executes a function that takes a raw data date of birth so a plain text date of birth and this function executes locally so there's there's no there's no way for this information to get dispersed to the service provider or to the platform and we can say I can prove to you that this date of birth is the date of birth that exists within this Merkel tree which is signed from a particular issuer and the way that you do that is you take the date of birth you hash the date of birth you combine that hash with the hash of the owner address to produce this path and then you combine these two hashes to produce the root hash so what you've just done essentially is you have produced The Root hash from a raw date of birth value that isn't expressed in the credential itself so if you're actually able to produce the root hash and the signature is verified then you can validate that you knew the date of birth that equated to this specific root hash so once we've gone through the process of a signature verification within a ZK program by again reducing a particular attribute to the hash combining those to produce the root hash and then verifying the signature associated with the credential we go through we go to the next step because after this has occurred we can assume that a zpass has been issued and the user possesses a record and a proof so we take all of the attributes that were presented and then converted into a Merkel tree into the record that exists on chain so now on chain there is a credential representation that contains the issuer's address it contains the leaf hashes for the Merkel tree and it contains the root hash and a signature all of this is encrypted onchain and can only be decrypted or viewed by the owner which is to say the person with the private key that owns this particular record on chain the next step is verification and here I have three different verifications that we could assume could be requested the first one is checking if the age is over 18 the second one is checking if the user is a US citizen and the third one is checking if the credential is expired once the user has completed all all of these verifications the result is a true or FAL output response and a proof If the result is true it means that the user passed these verifications and the proof attests to the fact that the user presented a valid credential that was verified and the information from that particular credential is what was used to verify these different claims this means that the user is able to prove to a platform that they are over the age of 18 they are a US citizen and that the credential they presented is not expired without exposing any additional information whatsoever now I'm going to go into some more code demo but before I do that um I'd like to just go into a little bit more explanation about Alo and the structure of Alo and how it works so I'm going to return to an earlier slide this slide here which which shows um the essence of offchain execution which was one of the main tenants of Alo Network um so just to run things back a little bit as I describe alo alo Network again is a layer one blockchain and it allows you to develop zero knowledge applications on chain that execute offchain and then maintain State onchain and there's a few different systems that Alo has developed to make it a lot easier for developers and Builders to begin leveraging zero knowledge proofs and build applications that can leverage zero knowledge proofs so to start with one of the things that's super important to recognize is that not any program can just be run to generate a zero knowledge proof the idea behind zero knowledge programs is they exist as a system of equations and so you have to be able to reduce some program all the way down to a system of equations that's structured in a way that has the ability to receive private inputs execute functions to produce execution transcripts and proofs that can then be verified so one of the ways that Alo supports the developer in this focus is we've created a highlevel language called Leo and what Leo does is Leo compiles down to Alo instructions Alo instructions is a lower level language that is then synthesi or that is then uh used to synthesize rank one constraint system which is the system of equations that allows you to generate and verify zero knowledge proofs usually you have to be pretty confident and comfortable with circuit language and understanding the Deep levels of zero knowledge cryptography and proofs to build and develop applications in this landscape but Leo has made it a lot easier to build and develop in a JavaScript type syntax and have zero knowledge proof or zero knowledge programs as the result so once you have this this is again this is what enables you to execute the program to produce proofs so this this is the workflow that as a developer you can get very used to on Alo the program is executed offchain a proof is produced and that is then again broadcasted to some validator node that verifies the proof and then updates the state of the blockchain so I'll go ahead and switch over now to some of the Leo code that I want to talk through um so everyone listening can realize just how easy it is to build zero knowledge applications using Leo and in the Alo environment so just to start off with one of the things that is important to recognize in the Leo model and in Alo is that we refer to Transitions um as or we we refer to functions as transitions uh transitions are functions that can receive records or they can receive state containing data objects that exist on Alo and they can execute functions around that information and then they can also produce records on Alo and Alo is similar to bitcoin uh as it relates to the utxo model so Alo has records which are similar to a utxo or an unspent transaction for those who are familiar with the Bitcoin structure and the idea is that uh a utxo or an unspent transaction or a record can only be spent once and so if you have a set of information or if you have a record on Alo and you present it as an input to a program the program will actually consume that record and then the developer of that particular program can decide if it wants to reproduce the record that it's consuming or if it does not want to do that but it's just important to recognize that transitions are the responsible functions for receiving the input of those records deciding on consuming it and then either reproducing a record for the user or not so in our case once we're at this point we can assume that a user has a digital ID they have a credential now and what they're providing as an input to this transition function is a signature and then a credential and at the top here I've I've um very simply defined what the structure of a credential might look like in this case again issuer leaf hashes and expiration date and then at the bottom here we have an additional uh data object which is the credentials Cipher text um and this is just an additional feature that we can tag on to the end of the struct of a credential that has uh an encrypted version of the hashed leaves in case we want to give the user a little bit more flexibility and understanding the information that exists within the credential but in the most privacy preserving way this wouldn't necessarily be included so a user presents a signature and their credential and once that's presented the transition function here says that it actually produces a signed credential which is a record on Alo so this transition function is not receiving a record it's just producing records it's receiving a credential structure and it's receiving a signature and as we step through this function we see that the goal of this function is to First identify that the person calling the function is actually the subject of the credential or the owner of the credential because we want to make sure that the users who are trying to claim some onchain representation of this are the people who actually own the information or who the information is about the next step is checking the expiration again this is as simple as comp making a comparison to the current date against an expiration value that exists on the credential and then finally the the final step here is Computing the root hash from the leaf hashes so even though a root root hash might exist within the credential it's still essential to compute the root hash because that's what the signature is verified around to ensure that there hasn't been a situation where the credential has leaf hashes that are not representative of what the root hash is representing itself and finally we go through the signature verification step so since we've computed the root hash from the leaf hashes we have the signature and we have the issuer address that's all that we need those are the three variables needed to verify a signature once we have a successful signature verification we can return assigned credential to the user and the user will receive this record if we execute in uh broadcast to the blockchain they'll receive this record on chain and within that particular transaction there will be an execution proof that represents proof that the information the user presented is valid and that the signature was verified so I'll quickly run this so you can see what it looks what the outputs like okay so maybe I'll start by showing the inputs here so it's very clear so again like I described earlier signatures presented and here's what a credential might look like and if we take a look here at the bottom of the screen we can see what an output looks like and again an output is a record that exists on chain so the output now has formed a credential in the form of a record on chain we have an owner address that is included we have an issuer address we have an array of leaf hashes and we have an expiration date now the user possesses this credential on chain and they can use it to verify themselves in different contexts I'm going to go ahead and show you what the verification process looks like like as well so you can get a feel for just how simple this is but again I just want to be clear here this is how straightforward developing using Leo can be and at the end of the execution of this function a proof is generated and that proof can be verified in a variety of different contexts or it can be sent to the blockchain when we look at the verification side so we have a verifi date of birth this function verifies that a date of birth is is equivalent to a date of birth that exists on an ID and then we also have verify nationality um and then finally verify age condition and verify age condition is the function that's responsible for actually verifying that a user is over some particular age like over the age of 21 so I'll step through this quickly verify age condition accepts a record and that is in the form of a signed credential or a zpass they accept uh a date of birth an age so this would be the age that you're trying to prove that you're older than a current date a condition so I guess you could be proving older than less than or older than and equal to less than or equal to um and so the condition value is what allows you to Define that and then an algorithm Boolean and this is just in the case that a different hash function was used we have a flag set to to say that the hash function function for this particular example was using Poseidon so when we step through this once again we do an assert to ensure that the individual calling the function and presenting a record is in fact the owner of that record on chain there should be no way that it's even possible to um present a record that you are not the owner of since you won't be able to decrypt the record unless you're the owner of it the next check is producing the Merkel tree and defining the path to the date of birth within the Merkel tree then we verify that the date of birth field is valid so we check that the date of birth matches the date of birth the the hash of the date of birth that's provided matches the hashed date of birth that exists within the credential and we continue through these steps of parsing out the date of birth turning it into a unex value REM uh subtracting it from the current year and then ultimately making a comparison against the value that we are able to calculate and the age that we're trying to check against and and one of the exciting things about zero knowledge proofs is they have the ability to provide a lot of privacy preservation but they also allow us to provide guarantees around how functions or programs are being executed so when you look at this and you see the result that's produced and you see the inputs that it requires you can be confident that the the if the proof is valid and can be verified at the end that the execution that occurred is exactly what's represented in this function here and it is down to the level of specificity of this particular program since this program exists on chain so we can be certain that the proof produced came from this program we can relate it back to this program and we can be certain that any results or state changes that occur came came from this program as it relates to the outputs and the proofs so once we've gone through the different verifications of age we've selected the condition and we've proven that the user has passed this particular verification then the result is just true or false and and the proof can be used to verify that so I'll go ahead and execute that function now so everyone can see just how quickly this operates and runs so I've copied over the relevant information it's a credential structure here I presented the different inputs that I've described earlier when I run this you see it executes the program and it provides a response of true now this is just one portion of the development process on Alo so of course this is a great way to test by executing offchain by running through different test cases and examples and by walking through to make sure you're getting the results that you would expect but the next portion is creating an environment where a user can actually interact with this program in a privacy preserving way and one way that we've been doing that at Alo is by expanding on the level of support that we're providing to Solutions like wum and what that does is this allows users to execute functions from their browser client side and the important part about being able to execute programs client side as it relates to zero knowledge proofs is it means that you can provide the inputs on your local machine so you can ensure that they're not getting sent or distributed to third parties or centralized entities and once you've executed that program which can be completely disconnected from the internet you're going to produce a result saying true or false Maybe or maybe saying some public value and a proof but because you executed it locally and you're just sharing the result and the proof with these other services there's no way for that information or data to get exposed so wam rust and wam web assembly allows us to create a safe sandbox environment within the browser where a user can provide information to programs and functions that can be executed to produce proofs which then can be verified in a trustless and privacy preserving manner that is everything in terms of the discussion in demo for today um I still have about 15 minutes so if there are any questions that are more technical or even if you have a high level question around zero knowledge proofs or Alo please feel free to um you know come down to the table I guess and and and grab a mic uh and and ask your question and I'll do my best to to give you an answer yeah um can you hear me better all right you said Alo is a private block chain in my mind that means there's no uh decentralized group of validators or anyone securing the chain it's one organization person controlling who can censor and whatnot is that the case with alio or are you saying private because all the information is encrypted can you can you say that one more time just the beginning portion yeah when you said Alo is a private blockchain in my mind the differentiator between private and public blockchains is who can validate trans transactions on the Chain so a private blockchain means it's it's uh permissioned only one entity can validate transactions on the Chain as opposed to a public is and but you also say it's encrypted so I just want to make sure I'm understanding yeah so Alo is a layer one blockchain solution um it is decentralized and it is privacy preserving as in the essence that every transaction that is broadcast to a validator on the network is done by generating a zero knowledge proof and then providing that in the form of a transaction to a validator node and a validator node is able to verify that proof and then update State accordingly and so it is public and permissionless in the sense that a variety of different validator nodes can validate transactions to update state but it is is private in the sense that any state information that exists on chain is encrypted by the private key of the owner of that particular address and then also on top of that information and transactions that are sent to validator nodes are done so in the form of a zero knowledge proof instead of the plain text information so they just have to validate the proof instead of re-executing all of the information like what is done on ethereum for example perfect really helpful thank you yeah great question and for anyone who didn't hear that last question the question was uh if Alo is a or or in my statement earlier saying that Alo was a private blockchain he asked for some more specificity around how interactions with validators worked and what I was acknowledging as the difference between public and private hello um what are the use cases that you guys are targeting now uh and being a layer layer one you know with the multi-chain thesis and layer twos how will proofs interact with the rest of the ecosystem okay just to rep what you're asking um are you asking what what are some of the other use cases as it relates to zero knowledge proofs that we've seen and how and and what is what is our role in the larger ecosystem as a layer one solution yeah I think specifically for Alo what are the use cases that you guys are targeting with your zero knowledge proofs and then how does that play into the greater ecosystem perfect yeah so I think the use cases that we we have leaned into a lot have been identity use cases specifically um we've put a lot of focus into this zass product to try and establish different opportunities to expand from this protocol and infrastructure uh across different business use cases so you can you know we all were very familiar during covid uh the the process of going to get a vaccine and then showing someone your vaccine card I think the medical field has a lot of opportunity for enabling better enabling users to own and share and express things about their medical history and in different instances like to insurance companies or to um you know for to for school to to gain access or to admission right you have to prove you've completed some vaccinations I think in a lot of these instances we're forced to overshare that one in particular where we could enable users to better protect their information and have a bit more control over it uh We've also done a fair amount ount of uh Research into um university structures so universities that have different credentials and information diplomas focuses of study and how we can enable users to better leverage some of that information and then from the finance space you know we we have kyc proving different information about your financial history proving that you might have some amount of uh funds in an account um to prove to to get provide proof of funds and then we've also looked at how the impact of zero knowledge proofs can help enable a more trusted and um reliable AI model so we've we've we've talked a fair amount uh about zkl and this idea of ensuring that the results that users are receiving are from a particular model that they have either paid for or that they are relying on on and I think that has a lot of opportunity to grow and impact the AI and machine learning space pretty dramatically as well um so ideally we're trying to Foster an ecosystem and a community of developers to be able to think through more unique and creative ideas to leverage this technology but we've tried to reduce the amount of effort and workload that it requires to get from zero to one in using zero knowledge proofs and implementing them into traditional applications hopefully that helps yeah sorry you're gonna have to come come down hello thank you for your presentation important subjective and you told about the verification the the the equation about the the how to validate and I have a question if I have my zass and participate to some Dows like I have my passport and I participate like the Customs Officer Down the alcohol markets down and these Downs validation if I have 21 or older age the custom officer validate if I I am a US citizen or if I am a Brazilian so I I would like to understand and how uh how can I have my z pass and participate to specific Downs to validate private ER informations about me if you can connect the zero nul Prof with Downs to specific subjections like oh this is the custom officer Dow if you participate to this Dow they will check if you are a US citizen or not you perm to participate this down ah if you participate to the alcoholic markets now they will check if if you have H 21 22 years old so not H assign smart contracts and participate to Downs to validate this these Zer nul Prof informations great great question so the question was there there's a variety of different uh Dows that may need to verify some information related to the organization that they're supporting or or the entity or the vision that they're supporting so there could be a alcohol focused Dow where it needs to verify that users are over the age of 21 and how can we use zpass to enable that through zero knowledge proofs to minimize the amount of information that's being shared publicly or or uh transparently um so great great question so to start off with the the first portion and the majority of what I just described is is mostly focused on the user experience and um enabling users to gain the zpass itself the next step to that is actually enabling platforms to verify so users produce the proof and platforms verify the proof so we also have built out a SDK and an API to support zpass um it is not public right now um but we plan to release that this year and the goal will will be to give different platforms and services such as a DA the ability to very easily integrate with the zpass API so that they can either receive um the proof the execution proof directly from the users who are trying to prove information about themselves so the user would have a zpass produce the proof and then they present that execution proof to the Dow and the Dow can verify that using the API or the user actually submits that verification on chain which produces a transaction ID and that transaction ID can be provided to the Dow and they can verify that the transaction was executed by your address um using the API as well and they see the result then and since validators natively verify proofs in that case the Dow actually doesn't even need to run the proof verification instead if the transaction exists on chain and it's been valid validated and is finalized then we know that we can trust the proof because every single transaction has to have the respective proof validated before it's finalized on chain so so so I guess the the short answer to your question is there will be an integration to support different platforms such as Dows to leverage this technology for their users as well my idea because Downs is like imagine a alcoholic markets maybe I'm use my my my point of view I buy something in City Market so City Market is the first member of the down and I allow the alcoholic down to check my information and after maybe alart participates to this Dow so I am a member of this Dow so I don't I don't need to know if Al Mark City Market Target who Market will will check this information I need to know the white paper of the down and this down can check my information so my vision about about the down is integrate all uh markets all all all kind of uh companies in one place where they can they can ER they can participate and I validate the down so uh in the future oh we need to know your your age and we need to know like your your physical your physical barer so the down will discuss with the integrants and the all all participants to the down to restructure the down and check the validation of the the participants so I imagine to the down a lot of uh companies uh to participate integrate and take discussions with the the the all the the all markets and the participants too absolutely absolutely okay it looks like that's all the questions for today thank you so much for the time I appreciate everyone listening in and please feel free to check out zpass at zp pass. o.org or check out just Alo in general at al.org um and you can also find me on Twitter at snark world so appreciate the time today thank you so much and have a great