# How Identity Revocation on the blockchain works

A **blockchain** is immutable. So what if you need to change something about your identity?

On this guide about identity management leveraging blockchain technology we scratched the surface of the **Identity Revocation** process. On this blog we will dive deeper into it.

**Contents**hide

## What is Revocation?

**Revocation** means deleting or updating a credential. The possibility for an issuer to revoke a credential is crucial to an identity infrastructure for the main reason that identities are dynamic.

**Attributes** can change over time e.g. house address or number of children, and some credentials should have a expiry date for example a passport or drivers licence.

The fact is however, that in order to ensure **trustworthiness** of the system and eliminate the possibility to defraud, credentials are immutable. After issuing, no one (not even the issuer) can change the information inside the credential. Hence, when attributes change, a new credential needs to be issued and the old one needs to be announced invalid. Thus, at each proof the users needs to proof that the credentials used in the proof are still valid. The **revocation registry** allows him to prove this without contacting the issuing party.

For example, the **Government** issues a credential to you, that you have 3 children. A month later your family is blessed with a 4th child. Now, the Government will mark the previous credential as invalid (stating that you have 3 children) and will issue a new credential stating that you have 4 children.

## What is a Revocation Registry?

**A Revocation Registry has 4 requirements:**

- – Credentials need to be revocable by their issuer;

- – Revocation needs to be straightforward and fast;

- – Testing of revocation needs to be privacy preserving;

- – Proving and verifying the proof should be possible without contacting the issuer.

The **revocation registry** is a complex mathematical concept, however to get the basic idea you can see it as a list of numbers (called factors) and each number has its an index number in the row e.g. 000, 001, 002, etc.

Now all these numbers can be assigned to a verified credential in such a way that each verified credential has its own unique number from the row. All the numbers multiplied together is called the accumulator.

Essential is that only the numbers associated to **non-revocated credentials** are included in the accumulator. Once a credential is revoked the associated number is excluded from the multiplication and thus the accumulator value changes, see figure 1.

This accumulator is crucial in proving the validity of a credential.

When an **identity** owner wants to prove that her credential is valid and thus has an associated number in the registry list she can show a verifier that her number multiplied by the rest of all the numbers together (called the witness) results in the accumulator.

This is the basic concept of the **revocation registry**.

## Flow: Set up, issuance, proof and verification

We will now go into more detail, following the flow from set up to issuance till proof and verification.

### Step 1 – Set up for a revocable credential

The first step in order to set up a **verifiable credential** with revocation registry the following things needs to be in place:

- Schema
- Credential definition
- Issuer must publish a revocation registry
- Issuer must publish the accumulator value that describes the latest status of for all the associated credentials

### Step 2 – Additional information for the identity owner

When an issuer issues a credential he will have to give the **identity** owner the following additional information in order to allow him to create a valid proof.

Additional information for the identity owner:

- The credential itself (file/.json).
- The index for this credential in the
**revocation**registry (posted on the ledger) such that the prover can look up his private factor (say a). - The product of all other factors contributing to the (current) accumulator (so only the ones associated to non-revocated credentials). This is called the witness (say witness = b*c*d).

### Step 3 – Required actions of the issuer of a revocable credential

When an identity owner creates and sends a** proof **he needs to prove that the credentials she uses in the proof have not been revoked by the issuer. He can do this through proving that:

private factor * witness = accumulator (latest update as stated on ledger)

In order for the **identity** owners to be able to create an accurate proof the issuer needs to always complete the following tasks:

Required actions of the issuer of a revocable credential:

- When a credential is revoked, the issuer needs to update the accumulator on the ledger (leaving this credential factor out of the multiplication).
- To ensure that other
**identity**owners can still prove that their credentials are not revoked, a witness delta will be posted in this transaction. Witness delta = a number that the prover has to use to adjust his witness such that his calculation (private factor * witness = accumulator) will match the updated accumulator.

### Step 4 – Verify a proof

The proof generated by the **identity** owner is send to the verifier. The verifier can check the validity of the proof by executing the following checks.

Verify a proof:

- Check the attestation using the
**DID**and verkey of the issuer. - Check the non-revocation by checking whether the latest accumulator that is posted on the ledger is equal to the output of the proof (private factor*witness).

We would like to thank Katja Bouman for writing this thorough piece.

If you’d like to read more, we have this Definitive Guide on Blockchain and Identity Management and the Ultimate Beginners Guide to Self-Sovereign Identity.

We just launched Ana, a digital identity management platform that allows organisations to issue tamper-proof digital credentials which are verifiable anywhere, at any time.