Who Vouches for You When Your Issuer Is Gone?

Transcript

[music] [music] So full disclosure, some of the research that I'm about to present here uh was done when we were back at the Ethereum Foundation as part of the institutional privacy task force before we spun out. Some of this research is from before then, but then some of it is after as well. When we were looking at identity systems back in around May or April of this year, we wanted to see how far we could push the cryptography and try to put it in the most adversarial situation as possible.

And it didn't take too much time for us to identify actual instances where identity systems started to break down and the issuer itself of these credentials became hostile. In 202 23 to 24 there was a government that revoked the citizenship of about 450 people and erased their identity records. All of these people all of these dots are people here and all of them were completely removed from all sources of uh government identity.

Now this poses an actual problem to our society and that is that the issuer itself can go offline can refuse new issuance can mass revoke existing credentials. They can publish false revocation lists. They can forge credentials for people who never had one and just go offline entirely. We looked at the existing solution space to sort of compare approaches and try to find one that would satisfy these requirements to oppose an issuer which would go hostile.

So on the left here you see that uh we go from least uh sort of okay most trusted operators to the least trusted operators on the right. So on the right we have something called an issuer independent OPRF. The OPRF here stands for oblivious pseudo random function. At a high level it's basically a way for servers to operate or perform some computation on data without actually seeing the plain text and they also return blinded data as well.

Now the easiest solution to try to do identity onchain is through registry membership but then based on the trust model that I just described it does not satisfy any of those requirements. Similarly, there are zkbased solutions as well, but most of them in some sense depend on the issuer still being up. To design a system that would work even when the issuer went offline, we have these requirements. So, the proofs should survive issuer failure. No single enrollment source should be mandatory. Therefore, tying back into

the pluralistic view of identity that we have, verification does not need to contact any issuer or off-chain service. And finally, you should be able to recover your identity without having the issuer in the loop. Keep these four in mind because the conclusion will sort of go through all of these and we will grade our own solution based on it. So the solution that we came up with is a combination of the OPRF system that I described earlier and almost all of the ZKbased identity systems that exist today.

So to describe the architecture, we have a few sources uh the holder itself of the credential and the VBRF network. There are a few more components but I'll explain all of the flows uh with time. You can basically imagine that the holder is able to use either their passport, their national identity, email, web to account, anything that sort of produces a zero knowledge proof that their credential is valid, takes that to the VOPF network, sort of blinds it and provides them some data which I will explain and then is able to generate something called an enrollment

proof which they use to join or sort of transition their credential from an off-chain system to Ethereum. Similarly, to verify proofs, it becomes very simple. You have an application that sort of asks the holder if it satisfies certain predicates and it also asks them to prove that u they might have a certain amount of reputation for example and the holder can do that without the issuer being active. I want to double click on how enrollment works in a little more detail.

So here we have the source holder the VPRF network and enrollment. The source here can be your ZK passport and on other self any other sort of ZKbased identity system. You take the proof that you get from them. You turn it into something called a pyink. Now the py link proof essentially canonicalizes the identity of the person into a succinct hash and then uses that hash to provide some form of information to the voprf network which is a 4 of7 MPC network which takes this blinded information and

returns a sort evaluation on this data to show that they have attested the fact that the pi link was formed correctly and they return a partial results along with something called a DLEQ proof which stands for discrete log equality proof. Finally with the partial results and the DLQ the holder of such a credential can generate something called an enrollment proof. this leaf or uh which basically says that this leaf comes paired with a nullifier that was honestly derived from the MPC's PRF applied to some request that I made to it. So what remains

private here is any uh anything related to your identity, the attributes of the identity and uh what remains public is the MPC network public key along with the leaf itself and the nullifier. Then finally the holder takes that proof and puts it on chain with some form of stake and that serves as a way for economic civil civil resistance. So what happens on chain is the contract checks if the nullifier is unused. It takes the stake and inserts the leaf. If we wanted to look at what the leaf actually contains,

it is essentially the identity secret or which is committed and various attributes of the identity of the person itself. You have a hash of their name and the day they were enrolled. Now, this can change with time based on your particular use case. So, uh you can add all the attributes that you need or even have it configurable. [snorts] Let's look at how verification works now. So here again you have the application the holder and the verifier contract. Now this app doesn't need to be onchain.

It can be offchain as well because the verifier can run offchain as well. The verifier asks the holder to prove that a certain attribute is being satisfied by their identity and the holder is able to generate the proof only when they can satisfy that ability that uh attribute. So they return the proof along with a nullifier which basically explains to the app or the verifier app that I haven't generated this proof before and this is fresh.

So the identity verifier is the onchain contract which can verify the given proof and therefore the verifier application can be sure that this identity is valid and this attribute is valid as well. Now, one could imagine what could happen if you had multiple applications that ask for proofs from your holder. And this is where you have to namespace the generation [clears throat] of the nullifier itself. Otherwise, it becomes easy to sort of deanonymize uh deanonymize a holder based on the application that they're using.

And finally, let's see what happens when the issuer goes offline. So, as I described earlier as well, you have the issuer that issued the credential. The holder has enrolled and then if they go offline, the holder is still enrolled and is still able to submit proofs to the verifier and the verifier then uses Ethereum as a resilient bulletin board. Essentially the enrolled holders keep proving and the verifier still accepts.

Finally let's look at civil resistance as well because this is something that really comes up a lot in identity systems. Uh there are few dimensions to this. First is the cryptographic way that we solve for uh civils and that is through the VOPRF enrollment nullifier which makes sure that only one leaf can be generated per person. Uh the economic side of things where you take 0.1 ETH this number is configurable and depends on the model that you have for your identity system. And finally, something that we spec specified and that's interesting for this specific use case is uh the three member vouching system where essentially to join this

sort of membership set you must be able to get vouchers from other people that attest to your humanity. The best part of this system is that it composes well with existing identity systems. So you have ZK passport, self anonadar, zk email, TLS notary and many more. And since the MPC network is just just exposes a singular common interface, you can definitely bring your own.

You can sort of identify a form of tier system for any identity source. So tier one would be something that can be zero knowledge provable and could definitely contain biographical data and that includes anonadar GK passport and then you have the second tier which is email and TLS transcripts where u multiple people could have the same email across different domains. So that there are definitely ways that it's not as strong of an identity source as the others which is government- based ID.

This solution does not come without costs uh and it is the recursive aggregation of this uh identity proofs that take up a wide amount of time. So you can assume between 1 to 5 million constraints per source verifier that is paid by the proofer once at enrollment. Membership proofs and gas do not change and they still remain relatively cheap. This again isn't the best solution for different use cases, right?

So if you have something that's that does not have an adversarial threat model then you could simply go with an onchain at a stationation system. But if you definitely want to keep your community working after the issuer goes offline. This is the kind of solution you should be looking into. Again, as I said, it's it doesn't solve all the problems and there are quite a few things we found uh that we take shortcuts essentially to try to arrive at this solution.

The enrollment problem basically shifts the trust from the issuer onto the MPC network. So instead of depending on a single issuer, you're now depending on four of seven altruistic uh MPC nodes and uh you really have to make sure that uh the these run these nodes are run by people who are trusted parties. The second thing we found is the grouping conundrum. So a public predicate puts each proof into one of at most 249 groups for example.

So if we take uh two attributes of an individual, one is their age being above 18 and one being their nationality, right? You can have only two anonymity sets for someone above the age of 18 either yes or no. And for countries it is limited to the number of countries. And if you start to specifically request certain attributes from the user and they identify as one of them or they are able to prove that they have uh satisfiable attributes then that essentially deanonymizes them because there are only a few number of data points that can uniquely identify you as an individual. The fix for this is

having universal predicate cert uh circuits with private parameters. Finally, there are some other limitations that are on the network level and uh we also talk about who pays for gas to get the identity onchain. And finally, we speak about secret recovery as well. But all of these can be addressed and we have addressed them in other research that we have done. None of this would be possible without all of the private identity work the entire space has been doing the last 5 to 10 years because we designed this system to work with any of them. I think they all deserve their

credit for contributing and making this possible. To conclude, we have we're looking at the same requirements that I set out in the beginning. One that is proof survive issuer failure and that is true partially because now we trust the MPC network. No single enrollment source is mandatory. Yes, because we as I mentioned we support all sources possible. And finally, verification contacts no issuer or off-chain service partially, but uh the predicates and the transaction graph could potentially leak. But these are problems that can be solved and uh depends on the exact trust

model that you're looking for to keep your community alive. Uh that's it from me. If you have any questions, please send them through. Thank you. Thank you. So you see that there are two QR codes. One to connect directly and one to do questions right now live. We actually have some questions. >> Okay.

>> Congratulation of the presentation. That was great of the work you're doing. >> So let's go with some some of the questions from the public. uh some of them are may be tricky but uh let's go one step by step. So the first question that we can answer is what happen if the holder loses their so on the resilience let's say of the system loses their enrollment proof and the issue goes offline can verifiers still check previous proof of that holder will the holder be required to regenerate proofs >> uh this is a great question actually so I think in our specification the sort of trade-off we make is that this system works only if you enroll

before your issuer goes offline because the issuer must provide that initial credential to bootstrap uh your identity. So if they lose their enrollment proof and then the issuer goes offline uh it wouldn't work in that situation. But if you've enrolled before the issuer goes offline then you will still be able to generate membership proofs that attest to the state onchain and without looking at what the issuer has. So, uh, hope that answers your question. >> Yeah. Well, that was really an edge case, right? So, great, great answer.

So, um, let's move with the next one. Um, maybe easy. Is this system chain agnostic? I mean, is this designed specifically for Ethereum layer 1 or is more agnostic in that sense? >> Well, uh, not exactly. As long as you can generate uh the zero knowledge verifier for your particular network in mind, it should work across any chain. But we designed it for the Ethereum L1 for the censorship resistance properties that it has. All right, great.

Uh we can move with next one. Okay, so how does this solve the people without tire one ID? So let's talk about inclusion here right also have any government agreed to accept or adopt this type of ID system while the adoption is >> uh this this is a great question so uh when you're thinking about people in the need of humanitarian aid they might not necessarily have all the forms of identity that pe that we do right now and I think the best way to sort of answer this question is to work with the

humanitarian aid organizations and then try to find some way to identify people and when they have a satisfiable way of issuing physical identity or a way to identify them then you can essentially take that to the next level by using that as a tier one ID source. >> Well, great answer. I mean working with the humanitarian aid organizations in this sense would be a perfect test case scenario, right? real life text scenario. Um let's go with the next one. We still have few minutes.

>> So your design well let me put here your design trust a fixed comedy of seven nodes for enrollment. What if that quorum were on open market instead with many independent verifiers comping and paid for use? Uh this is a good question and honestly I didn't want to think about the economics of such a system which is why I didn't design it that way. U but you could do it if you have someone that is helping pay to bootstrap this identity system. What we were thinking is that you would have altruistic organizations that run these MPC nodes in different jurisdictions.

That would uh be a lowcost way for them to participate as well. So they don't really need to be paid for it in the strictest sense. >> All right, great. I think we have a last question then we can I mean you have still few minutes so if you want to do more question we are here to answer. [snorts] >> Um well let me put here. All right. So as we saw that as you explained this this system could actually solve privacy inclusion and several open issues right in digital identity uh domain personally so it's more a personal question where would you like to see

this adopted first? Maybe you answer it before, but and at which scale. >> Uh, I actually like this question a lot because I'm able to explain um what thought went into this, right? A system like this would only work if you used it before things got difficult, right? So you have to absolutely use it in context before uh the issuer could go hostile. And essentially all sorts of freedom tech that is being built is being built for after the fact. And you have to account and build for systems that might be healthy before that. And where would I

like to see it adopted first? If you look at the first slide that I had and if you look that up, that's where I would like to see it solved first and similar regions as well. >> Yes. Well, I do actually have a question if I can. >> Yes. >> So, um that's a great use case. And what do you think in terms of potential uh institutional uh resistance? I mean how do you see I mean still on the adoption side how do you see this happen uh in the next short term if you can be very brief then >> we are yeah >> okay um >> I think we are right out of time so

sorry about that chitchat like later about this thank you again for this amazing [music]