Revocation of Verifiable Credentials on ION/Sidetree

## Background

For revocation of VCs, there is a simple solution where the issuer publishes a list of revoked credentials on their website ([RevocationList2020Status](https://w3c-ccg.github.io/vc-status-rl-2020/)). While this is pretty efficient and cheap, it has the disadvantage that the verifier needs to send a request to the issuer every time they check the revocation status, i.e. the issuer learns about every verification of a user's credential (there are some safeguards to limit the privacy impact of this though). Furthermore, the issuer could respond differently to requests - depending on who asks. There is no mechanism that prevents cheating or keeps a transparent record of all the modifications to the revocation list. The revocation platform is centralized and if the issuer no longer owns the domain, the revocation information would be lost.

An example of an on-chain revocation protocol is [EthrStatusRegistry2019](https://github.com/uport-project/ethr-status-registry). Naturally, this fixes the disadvantages from the centralized solution. But now, every revocation requires one transaction on the blockchain, in this case Ethereum. This can become expensive and also feels inefficient.

## Idea / Feature Request

The principles of Sidetree could be applied to revocation as well: aggregate multiple state changes and write them as one transaction to the blockchain.
Even though Sidetree is focused on Decentralized Identifiers, it could make sense to mix VC revocation and DIDs because then you can get the most out of aggregation, which improves overall efficiency.

**What's your opinion on adding revocation information to Sidetree/ION as well?** Basically, one could implement a custom patch action that deals with the revocation data. To me it seems more feasible to add this to one concrete implemenation (e.g. ION) than adding it to Sidetree itself, but also interested if you see this differently.

In my understanding, implementations of Sidetree are not limited to the standard patch actions but can extend them in their specification. This could look like this:

```json
{
"action": "revoke-vc",
"id": "some-identifier-of-the-vc",
"data": "optional-further-data-related-to-the-credential-status-method"
}
```

Each of these actions could be easily traced back to the DID owner who issued it. On top of it, different [credential status methods](https://w3c.github.io/vc-data-model/#status) for Verifiable Credentials could be built.

## Random Thoughts

For me, there is still the open questions how ["Late Publishing"](https://identity.foundation/sidetree/spec/#late-publishing) affects the revocation protocol. (Probably you can no longer be certain about when a revocation was visible to everyone, whereas methods such as [EthrStatusRegistry2019](https://github.com/uport-project/ethr-status-registry) write all data to a blockchain directly and therefore provide some better timestamping features.)

The [accumulator-based approach that is used by Hyperledger Indy](https://github.com/hyperledger/indy-sdk/blob/master/docs/concepts/revocation/cred-revocation.md) seems interesting as well. However, there you can't add custom data to a revocation transaction (e.g. declare the reason of revocation, point to an updated VC if the old VC is just updated and therefore revoked, ...) because the issuer just publishes a new accumulator value without even any details about which / how many credentials have been revoked.