Polygon Id

Polygon Id aims to build a service that allows Issuers to issue claims about Users (including themselves) in a way that Users can prove properties about these claims (in zero-knowledge) to a Verifier.

Disclaimer: Polygon Id aims to be a framework for projects that need to deal with Id functionalities. It does not aim to be a fully functioning Id ecosystem as other projects we have reviewed (Sismo, Interep, Keybase, etc.)

Concepts and Methods

Claim

A claim is a private tuple of the form

Example: A university could issue a claim of the form $\text{(Student Id, Diploma, [Title of degree, transcript, etc], [Univeristy address, University contact info., etc.])}$

Claims are supposed to remain private: only the Issuer and the User receiving the claim should know its contents. Additionally, the Issuer should loose all control and traceability of the claim once issued.

Identity

Polygon Id is somewhat more abstract than other related projects from this survey. It uses the concept of Identity. An entity is either an Issuer or a Holder. These two types of entities are captured by the same abstract functionality.

An Identity stores and creates claims about itself or other Identities. Importantly, an Identity stores at least one claim involving its private key. Such a claim, which we call Key Claim has the form:

In more detail: The User Id of the claim is the Identity’s Id. The schema of the claim is “Private key schema” (for simplicity, we think of this as just some type of context information that tells us that the claim is about the Identity’s private key), and the data field of the claim contains the Identity’s private key for Polygon Id’s system.

Identities have Identity states. The Identity state is the hash of the concatenation of the roots of three Merkle Trees (MT). These trees are: the Claims MT, the Revocation MT, and the Roots MT. Below is a depiction of an Identity state.

The Claims MT is the Merkle Tree of all the identity’s claims. This tree is private. The Revocation MT allows for revocating claims. The whole tree is public. The Roots MT allows proving statements about claims that were valid at some point in the past. Again, this tree is public.

Polygon Id proposes storing the two public MT’s in an HTTPS address or an IPFS link.

Identity states are posted on the blockchain by the Identity, and become associated to a timestamp.

Every time there is a change in the Identity state, the Identity updates its state on the blockchain.

A smart contract in the blockchain verifies that Identity state transitions (i.e., the update of one Id state into a new one) are performed according to some rules. The verification is a Groth16 verification.

Some examples of possible rules are:

• The update is made by the Identity itself, and not by an alien party. To prove this in zero-knowledge, the Identity creates a Groth16 proof that it knows the private key stored in its “Key Claim”. More precisely, the Groth16 proof is basically a Merkle proof where the information of the “Key Claim” leaf is kept hidden.

• No Revocation Nonce in the Revocation Merkle Tree has been removed. (Polygon Id does not allow to “unrevoke” a revoked claim).

• The Identity state update is made by some delegate party.

Next we present the most basic Issuing, Proving, and Verifying methods in Polygon Id. Later we will discuss some extensions.

Issuing claims (credentials)

Here we describe how an Issuer (which we call Id1) may issue a Claim for a Holder (called Id2).

Concretely, for Id1 (Issuer) to issue a Claim $C$ for Id2 (Holder), what Id1 does is to send Claim $C$ to Id2 together with the Merkle Proof that $C$ is in the Claims Merkle Tree of Id1. The latter, Id1, also sings Claim $C$ and sends the resulting signature $S$ to Id2, together with a proof that the signature has been generated using Id1’s private key (i.e. the key stored in Id1’s “Key Claim”).

To enable more advanced functionality, Id1 may send some extra data to Id2.

(Note, in principle, it is not necessary to send a proof of such signature since Id1 is supposed to update its Id State on the blockchain, and to do so it has to prove that it knows its private key (i.e. Id1’s private key), so Id1 is implicitly signing Claim $C$ at that point. However, it could happen that Id1 takes a long time to update the state —in this case, Id2 would still be able to prove statements about Claim $C$ in a trustworthy manner)

Proof and Verification

Now Id2 (Holder) can use a zk-SNARK to prove in zero-knowledge that:

• It owns Claim $C$. To do so, it proves that it knows a Merkle proof for $C$, and also that $C$ was signed by Id1 (Issuer).

• The values in Claim $C$ satisfy some properties (e.g. the Student passed at least one course with a high degree)

• The key in the Key Claim of Id2 is associated with the Identity Id that Claim $C$ refers to.

The Verifier checks the validity of such proof.

Extra features

The Revocation Tree and the Roots Tree provide some convenient functionality:

Revocation of claims

Each claim contains a metadata piece of info, a “Revocation Nonce”.

When a Holder creates a proof of a statement about a Claim, it also proves that the Revocation Nonce is not in the Revocation Merkle Tree (Recall that the Revocation Tree is public), and sends such proof to the Verifier.

Temporal proofs

The leafs in the Roots Merkle Tree consist of all the roots of the Claims, Revocation, and Root Merkle Trees of the Identity.

This allows Holders to prove statements about Claims which were true in some past timestamp.

For example, Bob can prove that he got his diploma before a certain timestamp.

The procedure is as before, but now one uses the appropriate Merkle roots stored in the Roots Merkle Trees, which is a public tree, instead of the most current Id state of the Issuer Id1.

(For the Merkle proof, Id2 uses a subpath of the whole Merkle Proof it owns. This subpath ends in the root of the Claims MT at the appropriate time).

Upgradable claims. Claims can be modified. To enable this, claims have a version number in their metadata and a reference to its previous version. To modify a claim, a new claim is added to the Claims MT, with appropriate metadata. All previous versions of the Claim have to be revoked; hence, the Revocation Merkle Tree is updated accordingly.

High-level discussion

The good

• Polygon Id is permissionless and decentralized. In particular, it does not rely on oracles

• Verification can be made on-chain or off-chain: the Verifier can be a smart contract.

• Claims are revocable, upgradable, non-trackable, they can be claims about past properties, and they can be made to expire.

The tricky

Polygon Id needs no trust except in the legitimacy of the Issuing Identities, and the way they make sure that their Claims adjust to reality.

For example, I can create an Identity to represent “University A” and start issuing diplomas to random Ethereum addresses (in this case, the Holder’s Id would be their Ethereum address). Note, however, that the credibility of “University A” would be damaged.

Notice that Issuers are forced to update their Identity State according to some state transition rules. Hence, even though it is true that some trust needs to be placed upon Issuers (as mentioned above), a malicious Issuer can damage the system in a limited way.

Note that Polygon Id is not aiming to solve the point above, rather, they expect either:

• A third party to build on top of Polygon Id, addressing such types of issues.

• Trusted Issuers to start using Polygon Id. E.g. a government could create its Identity on Polygon Id, and we would all know it is legit since the government would be signing with its keys (assuming we trust that the alleged public key of the government indeed corresponds to a public key controlled by the government)

A possible issue

It can be relatively cheap for an Identity to share claims with another Identity, as long as it is willing to reveal its private key. To mitigate this, one must ensure that the Identity’s private keys are linked to some valuable account or secret.