Revocation of Verifiable Credentials on ION/Sidetree

[nikolockenvitz]

Background

For revocation of VCs, there is a simple solution where the issuer publishes a list of revoked credentials on their website (RevocationList2020Status). 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. 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:

{
  "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 for Verifiable Credentials could be built.

Random Thoughts

For me, there is still the open questions how "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 write all data to a blockchain directly and therefore provide some better timestamping features.)

The accumulator-based approach that is used by Hyperledger Indy 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.

[S3bb1]

Following this discussion because we're currently in the same "step" when it comes to revocation of credentials. Our current solution is that we create a RevocationList2020 credential and using the ietf-json-patch action to replace the whole content of the did document.

Since this action isnt supported by ion or element we had to "fork" sidetree to reenable it. So basically not compatible anymore to ion or element. Also another issue is that, the MAX_DELTA_SIZE is default set to 1kb which is not compatible to the RevocationList2020 because of the whole proof attached to it, to be compatible to the Credential spec.

the idea of a custom action sounds really cool and would also be convertible back to the RevocationList2020 (with currently lacking the proof property of the credential)

[DrHouston]

I don't understand the need for revocation.

Just put expiration dates on every credential, and allow it to be replaced if the credential is updated.

Keep the med data indexed about whether or not the credential is "valid" based on whether or not the expiration date is before or after the current date.

In my opinion, things that are issued can't be revoked they can only be retired or expired.

[S3bb1]

@DrHouston But what about credentials which are getting revoked when they are "consumed", like a (basic example) concert ticket. If you want to go the decentralized way, this needs to be "revoked" when you moved across the ticket check, otherwise others could reuse this credential to get access as well.

Additionally, when you have a credential which gives you access to an office building and you resigned, the credential needs to be revoked as well.