Recently Pelle and I published ERC1056 describing an identity system for ethereum compliant with the DID standard. Decentralized Identifiers (or DIDs) are the core component of self-sovereign identity systems. Aside from DIDs a fundamental building block of a secure user-centric identity is verifiable claims. A verifiable claim consists of two parts. A claim, which is a statement, i.e. Joel is the author of this article, and a signature from the identity that makes the claim. In the uPort protocol there are two types of claims, on-chain (using ERC780) and off-chain (using JWTs). This article will go through on a technical level how claims are issued and revoked in the uPort protocol.

A lightweight identity system

ERC1056 describes an identity system in which all ethereum accounts are valid DIDs. This is useful since it means that identity creation is free (as simple as creating a key pair) and that all existing ethereum wallets are valid identities. Furthermore it means that the system scales much better than any previous identity system based on Ethereum. All identities can assign delegates which are valid for a specified amount of time and that can be either revocable or not (more on that later). A delegate can be used both on- and off-chain to sign on behalf of the identity that assigned it. This includes signing of JWTs, ethereum transactions, as well as arbitrary data.

Using delegates in state channels

An interesting use case for delegates is state channels. The user’s identity lives on the phone, but user could assign a delegate to act on its behalf in the browser. Note that this requires the delegate to be added as non-revocable. Otherwise the owner of the identity could revoke the key before the state channel settles making all off-chain transactions invalid.

Verifiable claims

ERC780 is useful not only for on-chain claims but has features that are helpful for off-chain claims as well.

Off-chain claims and user privacy

One of the major concerns with claims is that they potentially contain private data that shouldn’t be shared openly with the world. By creating off-chain claims that are signed by a DID that is anchored on-chain, claims can remain private while retaining the security of the blockchain. Creating off-chain claims is simple. The issuer simply signs some data and encodes it into a format called Json Web Tokens (JWT). These JWT can later be verified by anyone. For more details on how JWTs work take a look at our did-jwt repo.

Revoking off-chain claims is trickier. JWTs might have an expiry date, but what if you want to revoke it earlier or if there isn’t any expiry? There are a few ways to go about this with different tradeoffs:

Make a revocation claim in ERC780. The issuer issues an ERC780 claim that contains the hash of the revoked claim. The verifier of the claim would then need to check the ERC780 registry to see that the given claim has not been revoked. This is simple enough and allows for granularity, i.e. you can revoke one claim out of 3000 issued claims. However this scales quite poorly if you need to revoke multiple claims at one instance.

The issuer issues an ERC780 claim that contains the hash of the revoked claim. The verifier of the claim would then need to check the ERC780 registry to see that the given claim has not been revoked. This is simple enough and allows for granularity, i.e. you can revoke one claim out of 3000 issued claims. However this scales quite poorly if you need to revoke multiple claims at one instance. Revoke multiple claims with one ERC780 entry. The issuer can issue an ERC780 claim which points to an ipfs hash. In the referenced ipfs object contains a list of hashes of claims which have been revoked. This system can be further optimized by putting the hashes in a merkle tree and adding a bloom filter.

The issuer can issue an ERC780 claim which points to an ipfs hash. In the referenced ipfs object contains a list of hashes of claims which have been revoked. This system can be further optimized by putting the hashes in a merkle tree and adding a bloom filter. Issuing claims with an ERC1056 delegate. By revoking the delegate of an identity all claims signed by that delegate will automatically be revoked. So if you want to revoke a lot of claims at once this is the way to go, the only drawback is that you have to revoke all claims made by the delegate. This works by issuing claims with the DID as the issuer, but the delegate as the signer of the claim.

On-chain “Badges”

ERC780 is an api for issuing, revoking, and looking up claims on-chain. But what is an on-chain claim really? I like to contrast claims (or badges) with non-fungible tokens (NFT). A NFT has dynamic ownership and you can send it to anyone. Badges on the other hand are given to an identity and can never change hands. It could be an indicator of a particular achievement or status within a group etc. We think that badges provide really cool benefits not offered by other types of systems on ethereum, but we are also weary of the potential privacy issues with putting too much data on-chain.

Finalization of the standards

Some people have been asking when ERC780 and ERC1056 will be finalized, i.e. merged into the EIP repo. We are eager to make that happen but we want the user experience when using these standards to be as good as possible. Therefore the plan is to integrate ERC712 once it’s finalized which provides the user with more information when signing data.