Building ZK Products That Solve Real World Problems: Identity (zPass) | John Reynolds - Aleo, ZPass

it's funny cuz she said you know the title initially that I proposed was building ZK products to solve real world problems and our marketing team got a hand on it and it turned into building the antidote to the identity theft virus um so this is where we're at now so to kick things off to to start with a really a startling statistic 86% of consumers worldwide have been the victim of some form of identity fraud it's estimated nearly $50 billion a year is lost as a result of identity fraud and $28 billion of that is tied directly to Identity fraud as a result of some form of data breach one one of the ways that was just recently described as to how a lot of individuals feel about their user data on the web is hopeless uh they don't have a lot of Hope in being being able to have their information secured and they don't have a lot of Hope in being able to have these platforms very motivated to secure their information and so what we've seen week after week is these headlines from Big tech companies that have been leaking user information or user information has been exposed in and it's as a result of this centralized in client server model that we've all gotten very used to I think it's clear and obvious to say we are all very well aware that we have a problem and it it's a very big problem and it goes back all the way to the beginning of the internet where we didn't have a unified identity system we also didn't have encryption at that time and a lot of these paradigms have continued to exist and actually Foster a benefit for these platforms and these big tech companies and as a result of not having these identity systems a lot of these different companies leaned into developing or building their own authentication systems and this led to a patchwork of ad hoc identity systems across the web none of them solving each other's problems but solving at least the problem that they were having which was understanding or acknowledging who their customer was and how they could interact with a specific user and have knowledge of their Identity or their information so naturally when you have a problem it's an instinct to think well why hasn't this problem be been solved yet why is it that we're forced into this Paradigm where we have to share a lot of our user information with platforms and big tech companies and I think there's two distinct Pathways or positions or perspectives that you can have on this well sure surely there's more but the two main ones the two main angles that I think are worth focusing on is the first being incentives are not aligned so a lot of these platforms have benefited immensely from this Dynamic where their users's activity is a bit more transparent they have visibility into the user's Behavior so they can personalize features so they can create marketing strategies or business strategies that are targeting specific things as a result of this information that they're able to gather the second angle I think that you can take on why this hasn't been solved is it's a very hard problem so identity spans a variety of different contexts and depending on the industry that you're in whether it be Trad by or whether it be a social media the amount of information that the platform needs to know is very different and the context change not only the amount of information but the level of validation that these platforms need behind that information so this is a really challenging thing to solve and we've seen some attempts on it if we are just thinking about identity in the realm and in in the landscape of login we've seen some real attempts in trying to make this more efficient to improve the user convenience and to make it overall better and safer for the user and one of these ways is SSO so single sign on and what this allowed is it allowed a user to take their credentials from one platform and use them in another platform and so we started to reduce the amount of custom authentication systems that we were seeing grow across the web that continue to fragment user information and increase the dispersion of user information across the web so this was good this was a good step forward the only downside of this approach is that as you can see from looking at the diagram it kept us in a very centralized and dependent based uh Paradigm or relationship all of the nodes in these diagrams you can see rely on the center node the centralized entity to provide their information and so even though we may have had a bit more convenience and interoperability with our information we were still in a client server Paradigm where we were forced and we continue to be forced in exchange for access to have to give up our information and so a server requests information and a user provides that and the server verifies or processes and verifies and stores some of that information and then the user is given access and this is the cost of accessing platforms and services now on the web we share information we are the product and they gain from that in some Capac capity and often times unfortunately our information gets leaked and I don't believe in some cases that platforms are as motivated as they should be in protecting that user information but ultimately the architecture of our system comes to blame so this is where zpass comes in and zpass is an identity solution that is built on top of alo alo is a layer one blockchain that integrates zero knowledge proofs into the transactions and it has a ledger that is encrypted so unlike ethereum when you go on to uh an Explorer on Alo you can't see the information related to all of the transactions unless you are the owner of a private key that executed that transaction so users who are interacting with ao's blockchain are able to decrypt the specific interactions that they're making with the blockchain but users that do not have the private keyword not able to or are not interacting they're not able to decrypt other people's transactions so what zpass is trying to do is it's trying to exist as an identity solution leveraging zero knowledge proofs in the blockchain to give users more control of their information but also to flip us into a prover and verifier Paradigm where instead of as users being forced to provide our personal information with servers we generate a proof around some information and then we provide the proof to the server which verifies it and then grants access to that particular service so to provide a visual of what this means or what this can look and feel like zpass allows users to shift from this Dynamic where all of their information on their ID has to be shared in order to for example prove their age in this case if you go to a bar and you want to buy alcohol you present your ID and a lot more information is shared with the bartender or the cashier then is necessary the cashier actually doesn't want to know all of that information either to be frank but all of this is shared when in reality they only need to know the date of birth and and it it goes even further than this and this is one of the great things about zero knowledge technology is it allows you to create proofs cryptographic proofs that can be proven to meet some certain outcome or prove that some statement is true without having to reveal the underlying information and so instead of even having to expose your date of birth we can go a step further and only show the predicate which is to say instead of a user having to give up their date of birth they just have to provide a proof that will tell the platform that they're over the age of 21 and we've seen a lot of Regulation um and and compliance reties starting to push forward in the identity space and with different uh individuals of different age group groups and uh different interests interacting online we believe that zpass is going to be a great solution to provide users more flexibility in how their information is used and how it's shared with platforms and the amount of information that is used and shared so like I mentioned this moves us away from a client server Paradigm where Paradigm where plain text information is getting sent to a server and it shifts us to Ave or verify Paradigm where users are in control of their information servers are requesting proof of particular criteria the user generates that proof from their information and that gets shared with the server which verifies it in this instance the server gets a general amount of information based on the criteria that they've set is required and the user gets to uh reduce the amount of personal information they're having to share so there's the same security and verification guarantees for the platform except the user's information is secured and private during this interaction and this allows us to shift even a step further forward from the Federated approach it eliminates that Central dependency on some third party or Central service and it allows users to be the owners of their information and then produce the proofs and share it under their own free will and their own circumstances this means that that platforms are interacting directly with users for their information and they're also reducing the amount of information they're getting exposed to and while I said at the beginning there's certainly interests from Platforms in gaining this visibility and transparency into their users and so there has been some resistance to moving towards more private protocols with a lot of the regulations that are getting pushed forward today and a lot of the understanding improving around some of these risks as it relates to privac and security a lot more platforms are starting to recognize that they actually want to reduce their liability in having to secure and manage all of this user information and if there's a way that they can reduce it to a statistic where hey we had X number of users over 21 or within some grouping that's actually going to allow it's going to equip them with opportunities to Market and strategize but it's going to also prevent them from as many liabilities in the long run so going back to Alo quickly um speaking about Alo as a ZK layer one blockchain the way that Alo works is it has a set of programs that exist on chain in a program registry so you can think of this very similarly to a Smart contract and what happens is the actual execution of programs occurs offchain and the reason that it's able to do that is because a zero knowledge proof is generated in the process of the program being executed so this means we can move the entire computational expense of program execution into an offchain capacity generate the proof have the proof sent back in a transaction to the blockchain and then have a validator node receive that proof verify it and then update the state of the blockchain this gives users the ability to on their local device execute functions using their own personal data and information with an air gap from the internet so the user has some form of digital credentials or ID and they need to prove something from that to some platform they're able to execute a program and a function locally on their machine produce the proof and then wrap that in a transaction that is either sent back to the blockchain and finalized on chain or even sent to a third party that is able to just find or that is able to just verify the proof on their own so for zpass again the process is creating a zpass which is creating taking a digital credential or creating a new CR uh digital credential and introducing it on chain you execute a function that will uh validate that credential to produce a zpass then you use a zpass to generate proofs around your information and that proof is shared to look at this in a little bit more depth so like I mentioned you can either issue a zpass and we have an SDK library that we've built out to allow users to very easily leverage specific signature schemes and then the Alo library for develop or for gener generating proofs but the other option is you can actually take a physical passport or physical credential and introduce that as a zpass and the way that that is done is uh passports are actually cryptographically signed so you can extract the information via an NFC chip and you can take the attributes from the passport you can take the public key of the signing Authority or the issuing authority and you can take the signature from it and you can verify all of the attributes were issued by some particular Authority through a signature verification and if this signature verification passes this means we can trust that the information about the user from the passport is legitimate and so we take that information and we put it into a record and that's coupled with a proof saying that this information that we are showing in this record came from a passport and we verified the signature of that passport the next step is generating the proof so like I said programs on chain have functions and those functions can be executed offchain locally on the user's machine so we have a zass which is a record and it you can think of it as a data object it has the user's passport information in it and then you have a function some sort of claim verification like checking that the user is over the age of 21 and then the result is a proof If the user passes this claim verification we we generate a proof which can ultimately be provided to a network so it exists onchain or it can be provided to a platform offchain who just has to verify this zero knowledge proof to attest to the fact that the user is over some particular age or even maybe not of some particular nationality if we're thinking of a more traditional Finance route where they're they're trying to avoid working with customers um from ofac sanction country I break this down a little bit more just to help uh every everyone understand some of the different components of this process because it's it's it's important to realize how this can really change the Paradigm of how we're interacting with individuals on the web so the idea is in the issuance process you have a credential with a set of attributes and a signature this might look like an owner a date of birth some nationality and an expiration in creating a zpass if you're issuing it we go through a process to reduce the amount of data that exists on chain or plain text Data even though it is encrypted we want to get to a place where we can reduce that as much as possible so we use a Merkel tree approach to produce a series of leaf hashes and then ultimately a root hash that gets signed by some issuing authority and placed into a record that lives on chain so once that gets presented and the signature is verified from that credential we're able to go into the process of generating a record which is a zpass and that proof that I mentioned earlier from here we have the ability to create proofs now from that record that lives on chain without ever having to expose the underlying data of the user or the user's information the zpass record by the user can get presented to a series of verifications the ones I've mentioned here is over the age of 18 a US citizen and that the credential is not expired if the data in the record is able to attest to these different values and the user passes these verifications then the next step is generating a proof in the result true or false if the user passed so if they've passed all of these verifications and the final step is to produce the proof and if the they've passed again the the result would be true and the proof will attest to the fact that the user presented a valid ID with a valid signature that met these different parameters so that is um everything from my side I hope everyone enjoyed I hope that give you some more perspective and understanding into how zero knowledge proofs can push us from a client server architecture to aover verifier architecture that allows us to not only protect our user information but also gives platforms a way to avoid some of the liability and risks of having to secure and maintain and manage user information um if you have any interest in looking into the solution a little bit more you can check out zp pass. al.org um we also have a demo on the website that you can step through to see what this might look and feel like uh we also if you visit zp pass. tools. al.

org we have a demo of the SDK and some of the different features that you can leverage offchain and in an onchain capacity so thank you so much everyone for the time and I hope everyone has a great day