Polygon 🛠️ An Introduction to Polygon ID

I am Alexander Brienne. I am a technical lead at Polygon ID. And today I will talk about what Polygon ID is in general, and about our new feature about our new feature — on-chain release. So, what is Polygon ID? Polygon ID what is Polygon ID?

Polygon ID is a sovereign identity solution that leverages the power of zero- disclosure evidence. As with all sovereign identity solutions, we have a trust triangle where there is the owner of the identifier—the of the identifier—the regular user regular user who has their credentials; Then there is the issuer that issues this data, for example, the government, a KYC for example, the government, a KYC provider, or even the user themselves, which I will talk about later which I will talk about later . On the other hand, the third party is a verifier who asks the user questions: prove that you are over 18, or show your credit rating, or prove that your country of residence is not on the blacklist, or something similar. For the release part, we have libraries, they are open source, and we have two main methods for issuing credentials. The first is the signature method.

It is based on Baby Jubjub's signatures. The issuer simply signs the account, and this is done off-network. This is effectively a free release of credentials. Nothing happens on the blockchain, but you can still verify this data on the network. Another way is to use Merkle trees.

In this case, the hash of the credentials is added to the Merkle tree, then the hash of this tree is published on the blockchain, and this way it can be confirmed that this data was issued by this particular issuer. But the tree itself does not necessarily have to be on the blockchain in the case of an off-chain release. Only the hash of the root of the tree should be published on the network to ensure verifiability verifiability . So, how it works: the issuer issues the credentials. We use JSON-LD format for verified credentials.

This is a W3C standard, and the owner of the ID gets them in their wallet, and then the verifier requests the appropriate evidence, and the user, using their ID wallet...It's a separate wallet. This is not a cryptocurrency wallet. This is an identification wallet. It can generate zero- disclosure evidence and provide it according to the verifier's request, or it can apply selective disclosure, i.

e., for example, that my country of residence country of residence is this specific one, or something else. So, I briefly mentioned that you can use Merkle trees to issue credentials, and there are generally two main types of credentials that a user has. So, the first one is his identity keys. He can have many of them, and they are interchangeable.

He can add new ones and revoke old ones. And he can also add credentials issued to him or someone else. And then all these identity trees, um, identity states um, identity states —that's, um, maybe I'll expand a little bit . So this Merkle tree of assertions is just one part of the identity. We also have a revocation tree in which we store revocation nonces.

This is simply a random number that was included in the credentials themselves. So we can revoke this data and the user will no longer be able to use it. But the most interesting thing about this recall tree is that the user himself retrieves data from it. It is public, and within a zero- disclosure scheme, it proves that the data has not been revoked. Therefore, when the verifier asks for something, the user does not reveal any identifiers that can be associated with specific credentials or with an identifier that they have used before.

So, we have the ability to have many different IDs for a user. He can generate a new identifier for each interaction, or he can reuse it , for example, for some site where he registered, then he will reuse this generated identifier. and then these identity states are published on-chain. this is the hash of these three trees. And the user can prove that he is in this tree without revealing his ID.

He just says, "Yes, I'm in this tree." You can check it out, but I'm not revealing anything about it . And what this assertion tree structure actually allows us to do— allows us to do— we usually use it off-chain, but it also allows us to implement identity and build trees on-chain. And this is a special case that we implemented, we call it " we call it " on-chain identity" on-chain identity" , and by extension, it's an on-chain issuer. which is capable of issuing credentials to users.

This could be a regular centralized issuer, for example, a smart contract could have a method that issues credentials to a user, but only the owner of that contract can call it. So, it's a kind of centralized issuance, but implemented online. But there is also the possibility for the user to issue credentials to themselves , based on on-chain data, for example, on-chain data, for example, they can issue credentials with their Ethereum their Ethereum wallet balance or proof of ownership of an NFT, and then be able to prove to someone else that their balance exceeds a certain threshold without revealing their Ethereum address and the exact amount in the account. And so, we have a lot of different tools for users. As I said, it's a mobile wallet, but we also have a mobile SDK for developers of other wallets so they can integrate it, and some have already done so.

We have an issuer node—an off-chain issuer node—an off-chain issuer, and a new one—an issuer, and a new one—an on-chain issuer, yes. And for verifiers, we have JavaScript and Go libraries, and for on-chain, smart for on-chain, smart contracts for zero- disclosure proof verification. Yes. Now I'll try to do a demo. What I'm going to show you now I'm going to show you now is the issuance of credentials by an on-chain issuer credentials by an on-chain issuer .

What it does: When you send a transaction to issue credentials, it gets the sender's address, i.e. the user, finds out the balance, and enters it into the verified credentials. This is not exactly the verified data stored on-chain. This is a smaller binary structure that we call a "core claim."

It is stored in a smart contract, and users will be able to retrieve it later using a library we will create. So far we only have this demo application, it's pretty simple, but it works. So, now I authenticate to this application using Polygon ID. It is running on my local computer. Now you see my DID, to which these credentials will be issued .

Next, I simply connect MetaMask, and through MetaMask I can send a transaction to the on-chain a transaction to the on-chain issuer to actually issue those credentials. Just waiting for the transaction to be confirmed. No, while it's loading, I'll show you what it looks like. So, on... looks like.

So, on... yeah, it should have worked. We have an on-chain on-chain issuer contract that accepts this request, and then there seems to be a timeout problem timeout problem . Maybe that was the problem. Yes, the backend was not responding.

I forgot to start the node. I hope everything works out this time. Yes. So, it was released and the backend was able to retrieve it from the smart contract. Then I just scan your code with my app, and, uh, the credentials are added, and now I can move on to the verification process.

So, I specify, uh, the credential schema, the credential type , which is balance. Then the issuer of the credentials. So credentials. So , our on-chain issuer also has a DID that comes from its Ethereum address. And then I can make a query to ask the user some questions, let's say in this example it's the balance, and I can ask if it's more than 1000, it's, uh, it's some big amount inside the credentials.

So, a confirmation is generated, and the verifier who asks this question, that the balance is, uh, significantly more than 1000, gets a positive answer. Yes. This is all from the demonstration side. Uh, do you have any questions? We are new to blockchain technology.

For example, uh, we want to create a DAO, and we want our participants to be able to, uh, be participants privately, and if they vote on something, should we use Polygon's zero-disclosure proof technology? Yes, you can, uh, use Polygon ID to implement voting systems. Uh voting systems. Uh , this is exactly what we want to, uh, see, these kinds of use cases for DAO. Uh use cases for DAO.

Uh , you can give someone credentials that they're a member of the DAO, and then they can prove with zero disclosure that they are one, but they'll vote from a different Ethereum address, let's say, just to break that connection and, uh, yeah, do it anonymously. Yes. So do users have to users have to ... They'll need to, they'll need to provide proof that, uh, they're participants, but the voting itself will be done through a regular smart contract. Okay smart contract.

Okay , thank you all.