Standardize the key revocation list

[satazor]

Currently the specs state:

If a public key does not exist in the DID Document, it MUST be assumed the key has been revoked or is invalid. The DID Document MAY contain revoked keys. A DID Document that contains a revoked key MUST also contain or refer to the revocation information for the key (e.g. a revocation list). Each DID Method specification is expected to detail how revocation is performed and tracked.

This means that is up to each DID method spec to specify how to obtain the revoked keys list. The issue is that the data structure for this list is not enforced, reducing the interoperability of the data model for that list.

In my view, it's important to standardize the data model of the revocation list. The reason is that there are many use-cases where we might want to verify signatures of arbitrary data that was signed by identities. To do just that that we must:

• Verify the signature against a public key
• Check if the same public key is or was listed in DID document; in case it's in the revocation list, check if the timestamp of when the key was revoked is higher than the timestamp of the signature of the data.

It will become a mess for app developers if we don't have a standardized and well defined revocation list. More specifically, app developers we would need to create "adapters" to build a canonical data model of the revocation list.

Thanks.

[msporny]

@satazor wrote:

It will become a mess for app developers if we don't have a standardized and well defined revocation list.

Yes, absolutely agree.

There are two strategies we could employ here. The first is to make sure that revoked keys will exist in the DID Document at all times. The second is to use revocation lists.

Assuming we go with the first strategy, any revoked key will have one of three properties (still under discussion):

"currentStatus": "Revoked"   // tells you its revoked, but not when
"expirationDate": "2018-08-07T01:16:11.268Z" // tells you that the key has expired, but no reason
"revocationDate": "2018-08-07T01:16:11.268Z" // tells you the key has been revoked as of a particular date

It may be beneficial to do multiple of those properties together.

Option 2 may come out of the work on status lists (revocation is a particular subclass of status list): https://w3c-ccg.github.io/vc-csl2017/

So, keys could have status lists associated with them:

  "id": "...#key-2",
  ...
  "keyStatus": {
    "id": "https://example.com/mykeys/status,
    "type": "CredentialStatusList2017"
  },

... the downside here being that it takes just as many properties for the indirection than it does to directly embed that the key has been revoked in the key description.

[peacekeeper]

I think we will have several situations like this, where features of the DID document should be standardized but remain optional (because not all DID methods may support this). Besides key revocation, another example is versioning.

[peacekeeper]

Related to #166 and w3c/did-resolution#37

[jandrieu]

Closing as we have adopted this issue in the new DIDWG repo.