ZK14 - zkID: Advancing Privacy-Preserving Identity w Research & Engineering - Vivian Plasencia

Transcript

Thank you very much for the introduction and hello everyone. My name is Vivian Placencia and I'm the CKID team lead in PSC at the Ethereum Foundation and I will be talking about the CKID work we have been doing in research and engineering. So let's start. So CK ID is the short version of zero knowledge identity and it's a way to prove things about yourself without revealing any other information and you can prove things like you're older than 18 or your residency country or things like that.

So the SE team has been working on some projects. So here you can see some of them and one of those is the anoadar project is a CK protocol to prove at her ids in a privacy preserving way. Another project is CK PDF and this is a project where you can prove content about a PDF without revealing any other information from the PDF and we have been working on a lot of standard efforts like we work with the W3C and ETF div Linux foundation and more recently we have been working on the

profile for the C document and I'm gonna talk about that because it's also related to open IC which is a a new con generic construction that there is a paper and I'm going to also talk a bit about that too and another work we have been doing is on revocation which is a very important topic in CID and I'm going to also cover that. So the main motivation for open IC was that SDJWs are not unlinkable. So that's what is used for selective disclosure and they are not unlinkable because they will

generate you will get the same proof every time you you you use it. So the that's the main motivation for the creation of open AC and open AC is a generic CK construction it's a it's the mapping to EUDI high it map maps the EUI high level requirements of annex 2 and the construction is modular it means that it has some some blocks that you can change if if you want to make it postquantum and I'm going to talk a bit about that too and there are different formats for

credentials and there is a specific layer for that so it's not attached to a specific format you can use the format you want and not trusted setup is required is using spartan so yeah not trusted setup and it's compatible with existing identity system so not the issue doesn't need to change the the the signatures or anything like that. And in this link you can find use cases for open AC and more information.

Open AC provides unlinkability in credentials. So you can create CK proofs and then people like no one even if the verifier collude with another verifier. So they won't be able to link the proofs and it supports device binding which means that that the issuer will issue a credential to specific holder and then also with the verifier when the holder created SE proof. So it supports complete device binding and it now supports not in the paper you like in the paper you will see it mentioning but in the first version of the construction it was focused on age verification but now it supports generalized predicates

and I'm going to also talk about how we implemented that and it supports so far SDWT and MDL and M do and the current text tag is circum spartan and hierox. So this is the architecture of openac and this will happen in the holder device. So the general idea of the and the flow for a credential is the issuer will issue a credential to a holder and the holder will use it to with the verifier or the relaying party and then this process will happen in the holder's device and

the proof generation will be divided into two steps. The idea of this is to make presentations more efficient so that the proof generation will be very fast. So in the first phase is prepare and then in this phase there will be some preprocessing and parsing of the credential and verification of signature. So this process is completely offline. So it's it doesn't need to be done at presentation time. That's why presentation time is more efficient. And the show process which is the second one is the one that will run at presentation time and is where when the holder will

prove the predicates and the things that the verifier needs for verification and there is the this blank process to to prevent linking the the the proofs. So here you can you will see the unlinkability. So the first version of the project contain age verification. So in this second version of the implementation it contains generalized predicates. So in the paper you will see this you will see that this exist but in the implementation and also in there is not that we didn't have a solution for that

how we were going to do it. There are different ways to to do it and I'm going to talk about but first the predicate. So a predicate is what when you want to prove something about the credential like for example you're older than 18. There are also other predicates like like range proofs like you want to prove your income is in a range or also membership that your residency countries in a list of countries or not membership the same thing like your residency country for example is not in this list and you can also prove more complex expression like you have been working for two years or more and and your

annual income is in this range. So you can combine things and make it more like difficult and and more expressive too. So that's a predic case and that's what we were trying to solve to have more expressiveness and there are different ways to do that and one way could be to to have the set of predicates that you want and create a circuit for that and solve each one of them like okay I want range proofs then I'm going to create a solution for branch proofs and the same for membership and then you will each solution. But the problem with that is that it's not general like it's just

for those specific cases. Another solution would be to create a language a new language like a programming language for that and then you will have a parsing and all these things like the HT3 like everything like a compiler for that language and then it's more complicated but uh it's better as a solution. So for us since we are using scom and we don't want to complicate things or make it less efficient then we did this solution which is the mix like it's in the middle you can get a lot of expressiveness but also you can get um all these use cases. So I'm going to

explain how it's done. So the flow will be you have your expression and the expression can contain parenthesis or everything. So and any logical expression it supports any anything related to loical expressions. Then the expression will be turned into a simple sequence is a postfix notation. So I'm going to also talk about that and then it will be checked and the verifier will know if it's true or false without knowing anything in the middle. And here you can read all the document and it contains all the details.

So for example here we have the claims like date of birth, the income, the country and then you want to prove this expression. So you see that it contains different predicates and also a parenthesis. And what we are going to do is to take this expression and convert it that's an infix notation and convert it to postfix notation. So we will use shuntingar algorithm. So that algorithm you can use it to it's usually for math expression but it also work for logical expression and you can use this algorithm to evaluate the expression with parenthesis and everything or you can use it to convert to postfig

notation and in this case we are using it to convert to postfig notation because we want efficient efficiency in circuits. So it's more efficient to go from left to right to to check everything and then we don't have to we have the expressiveness of the parenthesis but we don't have to manage parenthesis in the circuit. Then how this is done is that there are also two steps here and the predicates are with you are a greater than and things like that comparing things and then the in the second part with this logical expression you have and or and

everything related to the logical operators. So having this predicates then they will be evaluated. So that's the first step. take all the predicates and evaluate them. And then the second step will be to evaluate the full expression in postfig notation. And so the steps are like you in the first step you have already true false and everything. So now you just have to with your expression you just have to evaluate that and then it will be like a stack.

You like the shinger algorithm it works like like that. You read the first in the expression. You read the first predicate and in this case is true. Then you push the true and then you read the second predicate because it's the next element in the expression is also true. You push true. Then you will go to the end and it's a loal expression. You will take the last two elements and evaluate it. Evaluate them and push the result. And now you will have true there. And then you will read the next token which is false and and then the other one is or you will pop both and then evaluate that. And we have true as the final

result and that's what the verifier will know. The verifier won't see the other things. They won't see if one was true or false. They will just see the final result. So that's the solution we did for predicates. But apart from that that's the solution for open AC for to avoid predicates because before it was just calculating the age and checking if it's older than 18. And then another thing we work on was revocation and revocation is a very important part in for identities and it's the process that allows an issue to invalidate a previously issue credential with so that verifiers can check if that credential is valid or

not. And we did a lot of research on that and mainly focus on mercuries. And here you can find the the article with all the benchmarks and all the details and everything. And we collaborated on that with the report with the div uh team and here you can find the report. So more people work on that too. And as a solution like as a summary takeaway main takeaway from this research was that non-membership proof in a list of robot credential is the most efficient way because the for merrist there were

two solutions. One if you prove membership in a list of valid credentials and then it means that your credential is valid and the other is is if you prove non-membership in the list of provoke credentials then it means that okay it's valid because it's not in the list of revoke credentials. So following that then the next step was like what is the most efficient Merkel tree for non-membership proofs and then um we needed to to use that right for revocation then we want to integrate this feature and then we needed to find that and there are two popular solutions for non-membership proofing mercuries one is

sparse mercur trees and the other is index mercurries And we wanted to have like an efficient way and we know that SMT is actually very popular but the tree depth is pretty long to prevent collisions and it's uh not super efficient if you want in CK it works well but it's better to not have this depth if you want to use it in C. So, so then we wanted to have like a more efficient solution and in this case in index mer tree is actually very good because you just use the tree depths that you need and you don't need like this long tree depth and that's why it's

kind of like for CK a more efficient solution and at the same time index mercury is using a normal line merry with specific depth And for semaphur some time ago we created the lina MT which is an efficient tree for membership proof and in this case it doesn't support no membership proof so we needed to find the most efficient way from me from membership proof and also for non-membership proof so that we can get the best from both world and that will be the most efficient three for non-membership. So that's uh we created a lin plus which is lin with the

non-membership feature and taking the efficiency for from the lin in the tree creation and then taking the non-membership feature the efficiency in non-membership feature from the index mer tree. So you can find here the implementation and more information. So this is a normal lin but in this case it will have the feature of no membership proof. So if you want just membership proof just use the normal lin but if you want the n membership proof you can use this one. And so how it's done usually in for n membership proof

you where you are proving like in membership proof you prove that your element is in the tree. How you do that? So you know that you are h your element is is a leaf. So then you have the mer proof and you create the fruit and it's the same fruit as the tree. So everything is fine. But what's the problem with non-membership proof? So how do you prove that? So the idea is that you should be somewhere in the tree in the leaves and you are not there. So that's the general idea for the SMT. It's like your index should you should you take your index and you should be a specific position and you are not there that value is not there. So that's the way it proves non-membership and in the case of index merry the way they the it

will be done is that you have a the list will contain the value and the next value and then your value should to be there. It it should be a leaf and if you know if you know that there is a leaf with a smaller value and the next value is bigger than yours then it means that you are not there. So then you will take the membership proof of that specific leaf. So we do the same like we took this from this idea from there because for no membership proof you always need a way to have sorting or something. So then we don't take the other elements we will just

take the value and next value and there is this auxiliary note for to prove no membership for this the first element you insert. So that's the tree we will use for revocation and that's that's more efficient that normal non-membership proof trees and apart from that we also we also started to work on the SDK so that people can easily integrate the solution. So this is a work in progress. We plan since we are adding more features we plan to add more features to the SDK as well. So just for you to have an idea of how it

will work but this is a work in progress and we will continue adding more features to the SDK. So from the paper you can see benchmarks also in the resources I'm going to share you can check the latest benchmarks but you will see that this is for age verification just like in phone and you will see like proving time prevalent time verification time. So this uh is fine for real world usage. So so yeah it's like pretty efficient.

So what's next for open and ck ID? So now we want to integrate multivc linking and also is your hiding so that in the multivvc linking so you can link different you can get expressions and from different credentials. So verifiers can ask about different credentials. Issue hiding is the to hide the issue to the verifier because sometimes that's necessary and also the openc profile. So open AC is one of the solutions for the European EUDI wallet. So we have been working to create this profile because it will be added to the Etsy document

which is the document containing this specifications. So so yeah we have been working on that. So you you will see this soon and we will also work more on developer experience so that is easier for people to use it. Right now there is a demo and web like a phone and with SDK you can use it in web but we want to make it easier and also there will be a new version of the paper with this latest research and when we finish with multivcy linking and more like easier hiding. So we are we plan to explain all that too in a new version and we have been also working on a bit on postquantum openac the work will start

uh soon like more work but we already started a bit on that because the idea is to have an postquantum open AC and that's since open AC is modular we plan to to migrate all these modules to be postquantum And we also want to explore public registry the ID infrastructure on Ethereum. So we want to work more with ID teams working on Ethereum and to see how we can help. So please if you work on something like that, let me know and contact us. So I would love to help more on that. So you can see the C the CK road map here and it contains this these elements.

So here are some resources. So open AC studio is for like for you to see use cases and this is the paper I was talking about. So check check it out and this is the GitHub where we add all the research and documents. So thank you very much and if you have any questions please let me know. >> We have time for questions. Yep. Yeah. So what will be the use case of the implementation of using the open AC SDK? like let's say I have an IDP which is an issuer like how do you see uh

using the open SDK in an IDP that it's issuing credentials just to understand uh this scope >> yes so open AC is more like generic for any credential and so it's more in the it will run in the holder and for use cases it will be like the age verification so if your credential contains your date of birth for example you will be able with this you will be able to prove that you are older than a specific number without revealing your date of birth or any other information in your credential and then the verifier will know that you're older than than specific number but without knowing anything additional >> and does the SDK needs like any external connection or web three connection or

something or a specific deploy contract or something like that just to >> no not contract no and we did actually some research on that but Spartan Um yeah so there is not verifier onchain and it won't probably be efficient but that's something that we also would like to have but so not no not contracts. >> Okay perfect thank you. >> I think there's another question over here. Yeah. >> Hey um I don't know if I missed it but you mentioned unlinkability and revocability. Uh is there also something against replay? So like let's say I have a credential uh I use it to generate a proof that I'm 18 or more. Uh what if I

give my proof to someone that is not 18? Can they verify or is there a mechanism that prevents these kind of things? >> Yeah. So I device binding. >> So you this system will make sure that your proof was generated in the same device that the issue used to issue the credential and then the verifier will verify that. So yeah. more questions. No. So with that, let's thank our speaker once again.