ZK Whiteboard Session – Module Twelve: zkID with Oleksandr Brezhniev

Transcript

foreign [Music] and welcome to another session of ZK whiteboard sessions and today I'm here with Alexander from polygon ID and we're going to be talking about the centralizik identity and how is your knowledge proofs fit into that so hello Alexander thanks for having me thanks so um let's start out with giving a bit of context like how do you think about the identity and you know what different types of identity are there like just to set the context for for the conversation yeah so there is two big groups of uh

identity we can say that there is physical identities it would be like a passport driver license diploma maybe some some other paper paper documents basically okay and a big as a group is digital identities so with digital identities we have different subgroups we can say that it was an evolution of digital identities and first one was siled identities or we can say centralized ones

I guess what would be an example of a centralized identity so for example you have a website and you have login and passwords there so it's it's a type of centralized identity when you have just for each website you have your own login and password it's kind of like an account on the website yeah yeah we can we can think of uh digital identities as uh identifier or account and then some data that we can say it's it's a claim that is statements about this identity okay The Next Step was in evolution of digital identities

Federated identities so idea is that users don't want to have for each website new login and password it's much easier to have just one for example to use a Facebook account or use a Google account to log into different websites different applications and just not to have to remember [Music] passwords for for each website yeah I guess you also don't have to like type your name every time it just copies all gets copied over from Facebook so you know things like that it's a this

fighter Federated identity providers they're giving a lot of data they're storing it on their websites it it's like uh your name picture and email address maybe some some other data could be your social security number could be a passport data data and so on so and uh was there the main Next Step that we we are gonna talk today a lot is uh self-solver we're in identities or we can say decentralized

identities and so like just to unpack the term a bit what does self-sovereign mean like what is the diff What is the difference between let's say centralized Federated and self-sovereign like we're even just Federated themselves sobering what is the mean difference yeah main difference is that you are in control of your own data so it's not uh centralized in some database of of this uh one identity provider but it's on your phone on your devices and then you are sharing it with with others on on request so in a way I would say this is probably somewhat similar to physical identity because there I guess you also own the data like you own the passport

and whatnot is that is that the right way to think about it yeah it's very similar in the way that you're bringing your identity with you and showing one only when you need it okay makes sense and I think you kind of got start to get into it but I'm curious what are the pros and cons like you mentioned this is an evolution so I'm assuming every subsequent step is better but even if you compare it to physical ones um what are the benefits or like the downsides of using one form of identity versus another so for physical documents they have pros and cons so like with any identity uh you can easily lose your documents if if

we are talking about downsides documents could be forged uh they could be destroyed or you can just forget them at home when you are driving your car and you need to show driver's license and it's not with you so that's downsides but uh there's a good thing that a good property is that we want in digital identities also is that uh issue of this document doesn't know where we are using it okay so there is some degree of privacy yeah some degree of privacy but still the verifier the one who is looking at your identity

for example it could be policeman or it could be just a shop assistant or something so in many cases they don't need the full documents full information from from this document they just need to know that you're over 18 or you have permission to enter something or you have a license maybe to do something yeah and I guess giving out the document like reveals all the information in the document or at least most of it okay yeah the driver license in the US you actually have your address encoded so or actually written down there so it's not ideal to show it to a store clerk

whenever you want to buy something that requires your age check yeah okay make sense okay so that is pros and cons of physical let's move on to digital now yeah uh regarding centralized uh identities uh C load uh we can say that uh only the issue or the website itself actually who is uh giving you access to to the data knows that it's correct so it's not easy to Port this data to other places just showing a picture from website doesn't prove anything so you can not prove that you have balance on on

your bank account just by showing uh uh its own website so with with Federated identities it's a possible so data is stored on centralized servers and you give access to it to others it could be as we talked your profile picture your name could be your bank statement um yeah but the thing is that the issue is storing this data on its servers and its

tracking where you are using it first and also identity provider could just stop servicing you so for example if you have forgot your password your password you just cannot use it anymore or for any any other reason you may be blocked from a platform yep I guess well so to go back to privacy for example it seems to me that Federated identity versus physical institutions kind of reversed there the verifier can see data they

shouldn't see here I guess you can have the daily fire may be given like select access to a given field but here the issuer can see everywhere you use it right so like it's interesting and then as you said um Facebook can block you for whatever reason and then if you rely on Facebook to access other services now your blogs from all other services for uh so that's definitely not an ideal situation to be in um but yeah I guess uh but it's better than centralized right because you don't need security things right from every website still it's not easily portable between a different identity providers so you may have data on Facebook you may

have data on Twitter but you cannot just Port it to other sort platform to use data from both it's harder to make sense make sense but so what is the pros and cons of self-sovereign decentralized identity so for decentralized identity a user is in a center uh he receives uh identity claims uh and stores it them in in their its own wallet so and can share whenever he wants and is required maybe to access

something or just to publish uh tweet or some article it could be done in a form of a claim so it's it could be sort of it could be a document or it could be just some what I'm saying okay so it seems to me that like self-serverting identity kind of combines in itself the convenience of digital identity but also the the pro the properties of physical identities as well so it's kind of Best of Both Worlds almost yeah right okay awesome so um you mentioned a couple of times now claims and identities uh like what

are the different pieces of identists what are claims and how do they fit in and like we have issues verifiers like could you expand on that a little bit yeah so we we have we call this triangle of trust we have a user we have issue and we have verifier and between the issue and verifier we have a link it's not direct but it's

it's a trust so we can say that for this to work we need a verifier to trust issue and so like in the case of passport for example I trust that like U.S government has issued the passport if the passport has been forged that they you know the date of birth is correct on the passport because U.S government has verified it or something like that yeah and uh it's checked with uh just if if it's a physical document you can check that it it looks good it looks original not forged but with digital identities and self-solver and then it is you can be sure that it's a correct

one just by checking digital signatures yep so in our case user let's say we have University as an issue receives a claim about finishing some classes or courses it would be a diploma or something and it would be a claim issued from the University to the user okay so we we have this claim sent to to the user and then when user comes to

employer he wants to show that he he has some knowledge he has some trainings done and he can present this claim to the verifier but in our system we don't want to reveal the whole data if verifier doesn't need whole data from from this claim we can just say that yeah we have license and it's correct and for that we are using zero knowledge proofs okay so this is where SDK comes in so basically this is called the claim right

from something that is issued from the uh issuerto to the user and is there a term for this side or is it also just verifying a claim or something like that yeah it's a verifying okay fine and one other thing to ask in this case so we've been talking about the users being a physical person is that how we should think about it or could a user be like some machine robot or whatever or how do uh like is do we always want to tie identity to a physical user basically or a person yeah you're right that it could be anything actually identity and it could be belonging to a

user to a physical natural person or it could be a room it could be City it could be organization so and it could be just a pen okay it makes sense make sense um and then um as you mentioned here so just to confirm the ZK Properties or we use ZK proofs in cell solving identities to um make sure we hide some information right yes and um it only makes sense in the cells are in the context like for federal identity you don't really need a ZK proof right for example because the there is other ways to hide information

in that context there are some ways if identity provider Federated identity provider supports it okay if if it doesn't support them all the data is exposed I see and and the user cannot do anything with it because in this case for a fire goes directly to the issuer with without user user only gives permission to as a platform to give his data to verifier so in this case where fire goes directly to the issue and gets this data awesome awesome okay make sense Yeah in our case

um for this zero knowledge proves to work we need some public data and and some private data um yeah so I guess in the context of self-sovereign and identity um you know we talked about GK proofs but also I understand there is a blockchain aspect to it like how does blockchain tie into all of this yeah so we have uh here blockchain to store anchors of this claims on chain so for this trust link to work we need

identities of issuers to be published on chain and this identity states of of issue there including claims and in our case also revocations so when verifier receives this zero knowledge proof of some statement he also needs to go to blockchain and check that data referred in this zero knowledge proof is correct one and is on blockchain and so um kind of like to compare with Federated and centralized identities

basically instead of using a central database to store the data we're using blockchain but we don't store the actual data on the blockchain we store kind of like the commitments to the data you call them those anchors right yeah right so it's uh commitments and the actual data is stored on the user's device in a form of claims and of course users public private keys are stored also on the user's device okay makes sense and then I'm just curious I know let's say blockchains don't have high throughput and all of that stuff at least right now we are working on fixing that but for now and that could be a challenge when you need to verify me or

update claims periodically so if we talk about challenges with the system so like I'm guessing throughput is one but what what other challenges are there yeah it was a big challenge for us uh to solve and we found a way with um building a miracle tree of claims and then publishing only the Mercury root on chain okay I guess we'll get into the exact architecture in a few minutes but yeah okay that that makes sense any other challenges in terms of besides throughput or is that the main thing that yeah when we are talking about blockchain we need always to think about cost also like with this scalability we're also

solving this cost problem okay and I guess using ZK solves the Privacy aspect and okay and one of the challenges we wanted to solve was ability to use this not only outside of blockchain's identity and claims but also on chain so that's a big problem we wanted to solve and we solved it okay makes sense actually one other question that I I have about this so if we talk about like this is now the full system and you mentioned a few times like there is the revocation like what what are the properties so a user can get a claim from the issue and then the claim

kindness with an user but you also mentioned that um you know sometimes the claim can be revoked like could you talk a little bit more about like why this is needed or how this is helpful yeah imagine case when you lose your passport and you just don't want somebody to use it and or you lost your phone and it stores your keys your claims and so on and you need a way to revoke access to it revoke claims Maybe or it could be just for example are you sure decides to revoke because it's not relevant anymore for example a

claim could be that you are part of some Dao or a member of some group if you are not a member of this group anymore then issue May revoke this okay so this claims are dynamically updatable and in both directions kind of like but only they sure can revoke their own claims that's the I guess the advantage where in case of Facebook for example Facebook can revoke your entire identity here it's much more surgical uh kind of what specification can do yeah it's much more granular yeah so yeah all right so now let's dive into polygon ID what is uh what is the oval architecture how

do you guys implement this specifically like uh in polygon ID what are the different moving pieces yeah right now I will describe how it's this commitments work what we are publishing on chain what stays off chain and how it's working so we have issue and it has identity and for it to work we need identity State on

chain so this is this commitment that we're publishing on chain it's identity State we are calling it so and is it like a Merkle tree or is it a hash of something or what exactly is an identity state yeah identity state is actually a hash of three Markle trees the first one is claims Merkel tree the other one is revocation Street and third one

is Roots tree and it's not very obvious what is doing this Roots tree but we are adding this claims tree root into root tree and it allows us to prove different things without having to ask if you're to reveal New West State of Miracle tree okay and so claims are

put in into this tree and it's a binary structure and we have some fields in it we have claim schema we have identifier to whom it was issued and this claims tree is it like a map that Maps something to a claim or is it just like a you know is there like a public key that maps to a specific claim or how does it work so it's a sparse Markle tree and uh we are putting each claim in a specific

place in this tree so we have some Fields obviously claims that we hash together and it makes this pass in this tree okay and is that the identifier or is that something else it's claim schema identifier and some additional Flags got it so and of course we have data in this claim and for revocations is the same but we are putting here just revocation nonsense we we have them in

here in in the claims so each claim has revocation loans and when we want to revoke something we need to add the certification nodes to revocation tree and the path industry would be the same as path industry right for a given claim now it will be the location loans will be used as a pass okay I see and regarding root 3 so we are putting the updated Roots here adding from time to time like each time we are

publishing so it's kind of a historical record of the clean trees so it's a living tree we are always adding new claims there same for revocation we are updating it and uh for for the claims we are adding this claims tree root to this root string okay this makes sense now um this gets recorded on a blockchain right um right and um what is the like who does the updates how does that work if you could explain it so we have a smart contract on chain that verifies a state transition so it's a special

circuit that we have that checks that it's actually identity who calls is updating is updating this state on chain and it could be more complicated in the future like we can in future check that for example claims were not removed from this tree or relocations were not deleted and more complex maybe State transitions I think it might be helpful to go through like maybe an example of how a user would use a system to like let's

say I want to get a claim like I want some and get a claim from some issuer and then I want to use it somewhere how would this work uh you know yeah so imagine we have this University so university has running an issue and updating this identity States and claims so diploma would be of schema diploma for example then identifier would be users identity and the data that is actually grades and so on and if you're puts it in his

Mercury but also it signs it with with digital signature it it has keys and actually keys of public key of of the issue lives also in this tree somewhere as a claim so we have actually two types of claims it's kind of self-claims and also claims that identity is doing towards another identity and one question that actually I didn't think about before is so this identity state is that does each issue create a separate identity state for their claims or do all the claims from different issues are in the same identity state or

how uh like if you were saying a university wants to do it with the university create a different smart contract which stores a separate identity state only for this University or does it somehow get merged across different issuers all the issuers are using the same smart contract and they are updating identity states there but each issue has its own chain of identity States so I have mentioned uh State transition function and for each identity state here it is checked that this transition from previous state to a new one is correct so and it is the same for

different issues as they are running in parallel okay so that into States like are in the same smart contract but let's say Cambridge would have one identity State and then Harvard and Stanford would have other identity States and so forth and obviously for other types of issuers you would have you know also different identities okay make sense and I guess there is logic that enforces that if I stand for that I cannot update Harvard's uh identity status things like that yeah so it's checked in sizes State transition function yep because that is actually also zero knowledge circuit so in in future it could be more complicated

for cases like Dao you would like to maybe have different actors doing on behalf of the this identity doing some claims I actually would like to come back to it later about like how zero knowledge fits into this but let's finish the example first yeah so diploma as a claim would be added to this tree of claims and then it will be sent to the device of of user actually user will fetch it from from the issue so the issue would submit a transaction

that updates a smart contract on on chain that has this new commitment to the claim but the actual data the issue would give to the users uh you know device or whatever and that's how it gets stored okay yeah and uh at the moment when we have this published on chain user can now prove that he has this claim and he can generate proofs based on this but what happens if we if issuer doesn't publish it quickly like should I wait for 10 minutes

or one hour until it's published on chain so for for these cases we have actually digital signature that we can use signature from the issue to immediately use this kind of claims without waiting until it's published on chain I see and we we um it's the same more or less level of security but when it's published on chain it has additional properties like we can prove that this claim wasn't issued just now we can prove that it was added at some point

and also we can prove that it is a unique claim for example if we have a competition and we want only one identity to receive claims that he's a winner of this competition so with Merkle trees and Merkle tree proofs we can prove that this is unique claim and uh prove such kind of things okay and I'm guessing also if you just rely on signature you can prove revocation so like if you want to prove that the claim was revoked you do need to do uh check against the Merkle tree is that right

regarding relocations it it works the same with Mercury proofs and signature proofs so when issuer needs to revoke something he adds revocation nodes to to the tree and then needs to publish it uh uh on chain and from that moment it's not possible to use this claim anymore and it doesn't matter if it was Mercury proof of inclusion into this tree or it was signature proof from from the IC so even when you try to use a claim and using a signature you still need to include a proof that it is not part of the revocation tree yes okay got

it another question is um I'm assuming you know this the state will change all the time so if I have this data how do I know against like when I generate the proof how do I know against which state route to generate my proof uh so that uh do I need to keep all the data or kind of continuously monitor the update so how does it work yeah so uh this part the tree itself is private and it's not published anywhere but the revocation tree roots tree it should be public it should be accessible to everyone together with claims tree root so with that

uh identity could go and check that its claim wasn't revoked by just fetching the survocation tree and fetching the correct path uh to to the revocation loans and actually it doesn't need to fetch the whole tree and even the whole path just because it's not changing too much it would be maybe just a few levels that needs to be fetched and then hashes would match and that's also a privacy feature okay so the expectation is that the user needs to know about this they before they can generate a proof of the some claim

um they need to get this data from somewhere right and then for this this is known only to the issue that right okay and when is your creates a claim and sends uh to to the user uh he also sends a maple tree proof of inclusion into this tree uh to to the user and also signature proof okay like it's just digital signature together with claim and later we can prove that it's included into this Merkle Tree in in two different ways one is just having reference to some older state

of the issue that is published on chain and with this Mercury proof of inclusion into the tree and together with this two to other routes we can hash them together and get identity state that is on chain but it reveals a bit of information at least when this claim was issued and sometimes you don't want to say that when it was issued because maybe it was only one claim issued at the time maybe a small group and then it could be possible to reveal your identity and for such things we are actually

using this Roots G so you always can reference to the claims tree root in this tree and always generate proofs that are going to the latest state of the issues make sense so now we understand how the system works more or less and it seems to me that you know you don't necessarily need to have zero knowledge proofs everywhere you can you know verify signatures you can provide proofs for your mortal paths but obviously you mentioned zero knowledge Pro several times and I'm curious which parts of the system are they used for and for what purpose it is used for for privacy we want to

hide some data and we can generate proofs of some statements that are not directly inside the claims like age we could computate from date of births for example and also we can do authentication on some website or uh inside application without revealing your identity your claims and just proving that it is the same identity coming to this application so basically instead of you know a user giving a Merkel path to uh some verifier um wants to verify some claim and then

verify going and looking into these trees or being able to retrieve data from there what we do is the user generates a zero knowledge proofs and of course like they do the work they look up the data they make sure that it's not revoked and all of that stuff and then they give that proof to the uh to the verifier right okay and you also mentioned that zero knowledge proof is used here uh for some purpose what is that for and it's two controls that uh identity is doing State transition in a correct way so it's uh could be very complicated uh rules that wouldn't fit uh in just a smart contract some code so it could

check that you have claim for example that you are allowed to transition the state or it could be some some other Logics here so those proofs would be generated by the issuers is that right yes so whenever they update the identity State they would need to generate the proof that they didn't you know try to cheat and you know remove somebody if it was no reason or added somebody twice or whatever yes okay that makes sense all right now I'm really curious about the circuits that you guys are using um first let's start with the the ones that the user kind of uses to generate their proofs yeah uh so we can draw it in

a simple way the the circuit so we have zero knowledge circuit and it has some inputs some of them are public inputs and we need them to verify that commitments are correct that it it should refer data that is on chain or parameters that we are proving for

example age something that we need to verify on on side of the verifier and private inputs and for private inputs we are actually providing this the claim itself and also Merkel tree proof or signature proof that it was issued and we are providing uh prove that revocation wasn't revocation notes wasn't included into the issuers revocation G and on the output we have the proof

Decay proof and with that with with public data and zero knowledge proof verifier can check that the statement is correct and data is published on chain the encourse and be sure that user is following the requirements that this verifier sets so like to run to an example maybe to the university or checking age like what would be let's say public and private inputs in the in a concrete example so for example on Computing age we would provide the claim as one of the inputs

that has day of birth data and inside this circuit we are doing computations and we can we can do a few different operations we created generic circuits to do some basic mathematical stuff and just for example we can check equation of some data field we can check that it's less or greater than some value that we want or it's in the list for example if you want to make sure that

uh for example country of residence is in the list of allowed ones or not in the list like Blacklist of countries and these operations are going as public inputs and also the value that we want to check against for example it could be 18 for age or it could be a list of values for for these operations makes sense so basically you know the operation would be a public input let's

say if you wanted to verify that somebody is over 21 21 would be a public input and then you know maybe type of claim would be a public as well so that you know what you're checking against uh and then the claim itself would be private input I guess and then um like something about revocation should be a problem so as a private input we would provide non-revocation proof and also prove that claim was correctly issued it it could be a signature or it could be Merkel tree proof makes sense now it's interesting that

you provide the operation as one of the public inputs why not have like a separate circuit for every different operation or maybe even build it dynamically the problem is that we don't want to have too many circuits because for each circuit we need to do a trusted setup okay and we're using growth 16 as a proving system yeah we're using gross 16 and it requires a trusted setup and we want to minimize the need for it and for that we we've built a few generic circuits that can do such kind of operations and it covers a lot of cases and verifier doesn't need to have some

specific circuit write it himself or some some other Reliance or third-party circuits to to verify some data makes sense so you basically kind of like encoded this in a single circuit and you also standardized the schema so that the circuit works like for a given type of claim you have a given schema so you know that if you apply this operation to a given schema then it will the result should be correct right and also as a public input uh we are providing identifier of the issuer okay so and some some other data that we can

reference like this non-revocation proof and signature that is actually coming from from this issue okay so basically what this says is that you know I have a claim I have a claim from this issuer that proves that my age is uh you know over 21 or something like that that's kind of the idea right okay make sense so this uh so we get the zero knowledge proof in the end and uh I think you mentioned earlier that um you know there are two different ways to use it uh could you explain this a bit more yeah so with this ZK proof we can prove

something off chain obviously like we can log in for example uh to website and prove that we are allowed to do something on this website like to vote for some in cases like Dao or something we can vote for proposals and this is the off chain use yeah it's of chain use but it could be implemented also on chain if you want to do the same on chain and it would be a smart contract that is receiving zero knowledge proof and then you will be would be allowed to to do some actions inside this

smart contract like quote or withdraw funds or some some other actions and I guess this is probably one of the reasons why you need to go with growth 16 because if you want to post proofs on chain they should be fairly small you can go with some other system that may be a bit more flexible here but then the proofs would be much bigger yes so it was one of the restrictions we wanted to prove to be usable on chain but the other thing is that we want proofs to be generated on mobile phones and gross 16 allows us to do this pretty quickly and how much time does it take

to generate like an average claim proof I guess yeah we are working on optimization but right now it's about five seconds to generate the proof and we are working and I think it will be about one second to generate the proof okay but that's really good uh and I guess um that leads me to another question so um besides optimizations what other things are you guys working on or trying to build into polygon ID in the future yeah one of the things uh is also extending this query language to support more operations through more complex uh stuff uh optimization as I mentioned and also we are building

um platform so that issuers would be able to just call it regular apis to issue claims to do all the stuff without needing to manage the keys themselves and so on it's it's just for ease of use and of course the issuers could run our node and do it themselves also we are building at the station platform polygon verify is such source of trust in the beginning we are doing we can do kyc we can do some some other

stuff and this is uh very useful for different applications to provide civil resistance to provide for regulated applications prove that this person was checked against ml kyc regulations and we are working on on this different interesting so in this case would polygon be considered an issue or how does it work so polygon verify is an issue okay but we are aiming to bring much more different issuers kyc providers social media user himself should be able to

issue claims about others and about himself interesting okay well very exciting well I think this was a great session thank you so much Alexander thank you foreign [Music]