The Use of Zero Knowledge in Self Sovereign Identities

Well, hello everyone. Sara Rodriguez from Polygon Labs working on Polygon id, right? Usually I don't need to explain a lot about the company I work for in the space where I used to do these presentations because I am coming from the Web3 space blockchain, et cetera, and everybody knows who Polygon is there. Few people know who Polygon is in, in this more corporate environment, I would say. So we Polygon ID are developing a decentralized identity solution, and we are quite strong in the use of serial knowledge, okay? Since there's a movement in the back, okay?

We are very intense in the use of your knowledge for this decentralized identity solution. You need to understand that we are going in the, we are doing the opposite journey that most of the companies in this space are doing. What I have seen in these days is that most of the identity companies are moving from centralized to decentralized identities, right? We are moving from decentralized identities to mainstream adoption, right? So we are very intense in the decentralization, privacy, paranoid implementation of decentralized identities, right?

And we are moving to the mainstream while other companies that have already mainstream adoption are trying to understand or to implement the principles of decentralization, of and, and, and strong privacy in that context. And since, from a technical point of view, we're very strong in the use of your knowledge today. I want to share with you something more than this, right? So this is the obvious case of zero knowledge and identity, everybody. So before we start, because I think before me there was supposed to be another session explaining what zero knowledge is.

They want to check how many of you know what zero knowledge is, okay? There's other people that doesn't. So allow me to do two minutes, right? Serial knowledge is a crypto is a cryptographic technology that allows you to prove a fact about, about some data without sharing that data, right? It sounds very simple, but it's like magic. You can do a lot of things with this. The most obvious use of zero knowledge and identity, it has been described 10,000 times in all the literature, right?

Which is, yeah, I have a verifiable data with my birthdate and I need to prove someone that I'm over a teen without sharing my birthday, right? That is the most common example that you're gonna see a thousand times.

And yes, it's, it's very powerful, but it's, it's just the tip of the iceberg. As, as, as I I I I'm trying to share with you, there are other things that we are doing with serial knowledge and identity, right?

Sorry, the presentation is gonna be a bit technical. So I hope you, you, you can imagine the use of ology, even if you weren't familiar with the technology. First of all, we can do private credential revocations, right? Credential revocations in verified credentials is a, I would say no completely solved problem. There are multiple implementations, but privacy is always a concern.

The, the, our solution for this is very simple. We make the user to collect the data that proofs the non revocation, generate a serial knowledge proof, and share it with the verifier. That way the verifier doesn't have access and doesn't need access to the revocation registry, right? It's the user who provides the proof as part of a more complex proof. That is one case. The next thing is DID methods that support key rotation.

Key rotation is, is a another challenge for the centralized identities to the point that you can see things like K do you know K okay, K is quite a complex solution for a complex problem, which is how do you rotate your keys more? Most DID methods are based on, on keys, on, on the position of private keys, but then keys acts like passwords and we're used to change our passwords if our passwords get compromised, what do we do when our keys get compromised, right?

We need to be able to rotate them, but most DID methods don't provide a way to do that with, I mean, the way we do it is quite complex. But let's say that we use the blockchain to have an identity state and we use zero knowledge to prove that the transition is a valid transition, that we are not cheating. So only someone in possession of the previous key can change to the next key to do the key rotation, right? You can do that with keys, you can do that with other secrets or authenticators, right? And you can define different transition stage.

Like we could do social vouching, like if 10 people say that you own identity, then you're allowed to do something with entity is quite flexible. Again, the use of serial knowledge is, is crucial for this nullify for DID and tracking. That's another thing. Usually when you present a verifier credential, we talk about privacy and we, we tend to focus on the privacy of the credential.

So we say, how much information are you sharing, select disclosures, your knowledge proofs, et cetera, et cetera. But the thing is, when you're sharing your credential, that credential was issued to a decentralized identifier that you're exposing, you're, you are showing you that you, your DID to the verifier and that can be tracked across applications, right? And if there is a registry, imagine that you're presenting a verified credential.

Yeah, I'm proving that over 18, not my age to a porn site, okay? But my DID is registered there, right? And if then I use my DID something where I attach it to my real identity, I am doc set, right? And sharing my DID is exposing my activity across the, the network. Remember we are in Web3, we are defining this with paranoid levels of privacy. So we want to hide this as well. So we have created something what we call DID profiles, which is through a technical notifiers. We generate a different DID for each interaction.

So every time we speak to every fire, or even when we collect the credentials from the issuer, we expose a different DID that is derived cryptographic from the original DID, right? And the question is, okay, if I obtain my credential with DID one and then I'm presenting the credential with DID too, how do I prove that these are linked and I'm, I'm in pot possession of the profiles and the original DID serial knowledge proofs, okay? Translate, translate verification on chain.

Well, if you are not familiar with serial knowledge, the next two are gonna be like quite complex to, to decipher, but we can present verify credentials to a, to a smart contract, right? And that is very powerful because verified credentials are off chain information. They are not on chain, they are something created in a device somewhere. And you can verify something to a smart contract. The smart contract is a trust list application that is immutable and has many good properties. And usually one of the limitations is that nothing gets out of the chain.

Nothing gets into the chain with a level of trust. And here we are presenting verified credentials to a smart contracts, how we are not presenting the credentials because we don't want the credential to be stored on the blockchain forever. We're presenting a zero knowledge proof of the credential to the smart contract, right? And we have a language to do that. I think I'm gonna skip this one for the sake of time. This is quite, quite complex, but if you're interested, we, thanks to zero knowledge proof, we have a trustless issuer, right?

So you can do what self attestations and send a zero knowledge proof of, of execution to the blockchain. And then the blockchain acts as a trustless issuer at making the attestation from the blockchain that what you're saying is true. I'm really in love with this one. This is context based, unique identifiers. Unique identifiers are something very close to my heart because of the ethical and soci societal implications that they have.

Who, how many of you have heard of the pro of a project called World War Coin? Okay, they are, they're trying to solve a, a very well known problem, which is a problem of uniqueness, right? How we prove to online services that we are a unique human being, not just a human being, but we are not, we don't have 20 accounts to reap unfair benefits, right? Unfair rewards or whatever, right? We need to have a unique identifier like in the real world. This is gonna become more and more pressing as AI makes automation and deep identity, fake identities more easy to create and to fake, right?

So sooner or later we'll have our unique identifiers attached to ourselves. They can be attached to your person via government documents or biometrics. These are the two solutions, right? The challenge with this is huge because if you start sharing your unique identifier online, then you can be massively van for all services online at once, right? You are put in a black list, you cannot get another identifier of that kind, right? That is you who is being banned. It's not an account that is being banned. It's you as an individual who is being banned or denied services or whatever.

So it's, it's quite dangerous. And what we are proposing is context-based, unique identifiers. When a verifier asks you to provide a unique identifier, you can also derive cryptographically another one, like same as the profiles, right? But we generate a long set of knowledge proof that proves that that context based identifier is derived from a valid, unique identifier, from a valid issuer, right?

Like, yes, this was derived from bio biometric hash delivered by this provider. But what I'm sharing with this verifier is context based, which means it's only valid in that context for that verifier. Even inside the verifier, we can have multiple contexts that protects your privacy, that protects your unique identifier that should be sacred, that you should, you shouldn't be sharing it with everyone. And finally, select disclosure. And this is quite obvious, right? Elective disclosure is like a, everybody's used to it, but in the end, selected disclosure is not as easy as it sounds.

It's not just taking the verified credential and extracting the field. You need to secure the, the chain of trust between the verified credential and that piece of data. And there are many ways of doing it, like BLS or random credits, but we think serial knowledge is more flexible and allows for a lot more things. So I dunno how I'm doing with time, but I hope I, I convey the idea that when you hear serial knowledge in identity, right, you will see always the same example of I'm over 18 or other things, right?

Serial knowledge has thoses of applications that are more powerful than just hiding a, a data, filling a fire credential. Thank you. Thank You. So we do have time for a question or Yes. Okay. When I just bring the microphone too.

Oh, I'm good. You can hear me So, oh no. For people online, they need, oh, sorry. Alright. For all the people online. So everything you're using with the unique identifiers is this separate outside of smart contracts and actual Web3 wallets are used somehow privatizing unique identifier to a public private key from a wallet. I dunno if I understood the question. So if I'm gonna interact with a smart contract, I give my public key, right? And I sign a message with the nuns.

So you're saying you're gonna create some type of unique identifier, so therefore my, my identifier is me as my wallet won't get banned across all the different applications. Are you tying all this stuff back to a wallet or is this some completely different type of identifier?

There, there are three layers here. First you have an identifier to your DID, right? The DID is your decentralized identifier. And then depending on the DID method, you the, the secret that you control that gives you the rights to control that DID depends on the, on the method, right? Then you may, you may have an identifier, an authentication to the wallet itself, right? To the thing that connects your DID with your verified credentials. Then inside the verified credential, you can have all kinds of identifiers. Like your passport number, that is your unique identifier is we the block.

No system can give you a unique identifier that that's to your individual person except for governments and biometrics, right? And then there is the fourth one, which is in blockchain to send transactions you need an authenticator. An authenticator that is based on an Ethereum key, right? But these things are not necessarily connected. Cool. Thanks. Okay. Thank you so much Sebastian. Great to hear about that. And it.