Revoking Credentials

Revoking credentials

But what if the credential is no longer valid? Revocation is one of the most technically complex and nuanced aspects of verifiable credentials.

Revocation of credentials works a lot like the revocation of a physical credential in the real world. If the DMV revokes your driver's license, the plastic card remains in your wallet, but it is no longer valid for certain use cases (like driving). It may, however, be valid for other certain use cases (like proving your age, or that you were eligible to drive in the past).

How it works

When an issuer sets up its credential template, it has the ability to create a template that supports revocation. When revocation is enabled, something called a "Revocation Registry" is written to ledger. Essentially, this Revocation Registry is a massive number (called a cryptographic accumulator) that, through various entries by the issuer, enables a verifier to check whether a given credential has been revoked without compromising the privacy guarantees of credentials.

One (oversimplified) way to think about the revocation registry is like a particular color mixture. Imagine something vaguely yellowish. By looking at the mixture in aggregate, there's no way to know which individual colors composed it. Suppose now there is a very particular shade of blue associated with a credential in Bob's wallet. If he shares it, the verifier doesn't find Bob's blue color in the
color mixture, so the verifier assumes the credential is valid (isn't revoked). Now suppose the issuer revokes Bob's credential; when it does, it puts a small drop of Bob's blue color into the mixture. The mixture changes only slightly. But next time Bob wants to share that credential, the verifier checks the color mixture and (this is where the example breaks down a bit) through fancy cryptography can know that Bob's blue color is added. Therefore, the verifier knows that the credential was revoked.

Checking for revocation

In order to check for revocation, a Verifier will specify its revocationRequirement in its Verification Policy. Revocation is checked as of a certain point in time using a the following field:

"revocationRequirement": {
	"validAt": "2020-07-01T13:13:25.537Z"

When the verification takes place, the revocation registry is checked to discern whether the credential was revoked as of the timestamp provided. This timestamp is set in stone as of the time the verification policy is created. Therefore, the only way to check whether a credential is revoked as of right now is to create and send a verification based on a policy you create right now. That is why we created the POST /verifications‚Äč/policy‚Äč/connections‚Äč/{connectionId} and POST ‚Äč/verifications‚Äč/policy‚Äč endpoints--they allow a verifier to create a verification policy from parameters (ie, on the fly) so that you can set the revocationRequirement to the current time.

For example, if you create a verification policy on Monday, revoke the credential on Tuesday, then use that verification policy to do a verification on Wednesday, it will show the credential as being valid (not revoked), because the policy is checking for revocation as of Monday, when the policy was created. In order to check in real time, you need to use the POST‚Äč/verifications‚Äč/policy endpoint and supply a timestamp of the current time in the revocationRequirement.

Remember this

  1. Revocation doesn't nullify the whole credential, it doesn't prevent it from being used in verifications
  2. Revocation provides information to the verifier about how the issuer feels about the credential they've issued. It's up to the verifier to decide whether they will accept a revoked credential or not.
  3. The holder of the credential won't be notified when their credential is revoked.
  4. Revocation is checked as of a certain point in time. So to check whether a credential is revoked in real-time, a new verification policy should be created in real-time.