Proposed DID parameter: returnDeactivatedDidDocument (Discuss how to treat deactivated DIDs)

[peacekeeper]

This issue proposes to add a DID parameter returnDeactivatedDidDocument (or similar), based on discussion in an issue in DID Resolution:

w3c/did-resolution#5 (Discuss how to treat deactivated DIDs)

[ottomorac]

Hello.

During the DID methods call yesterday, @swcurran had mentioned that there was a requirement from Switzerland related to keeping deactivated DIDs of did:webvh as resolvable for specific archival purposes. Perhaps @swcurran can expand on the details of this requirement and this can help inform our discussion of how to handle this potential new DID parameter.

cc: @ankurdotb

[swcurran]

Some detail about what we think is needed are in didwebvh#241.

The query parameter is OK, but is far from ideal. It would be preferable for the DID Controller to decide what should be returned, and the DID resolver to receive what the DID Controller would like to convey, without having to resort to extra parameters.

Why not the extra parameter? To use it, every DID resolver (or the client of a DID resolver) must always:

1. Resolve the DID
2. Check if a the DID is deactivated and if so,
3. Resolve the DID again, this time with the returnDeactivatedDidDocument parameter

Or, alternatively, the client could resolve every DID with the returnDeactivatedDidDocument parameter, on the off chance that it is resolving a DID that has been deactivated.

With did:webvh, and presumably other DID methods the DID Controller has the following options:

• deactivate the DID and set to empty ({}) the DIDDoc (previous DIDs may be available, if the DID is capable of that).
• deactivate the DID and leave the existing DIDDoc intact for archival purposes
• delete the DID such that a resolution results in a didNotFound status.

With did:webvh, there is the added option (to workaround the need for the extra query parameter) of setting the updateKeys parameter to empty ([]) to indicate that the DID is no longer updateable, without setting the deactivated flag (even though it would be preferred to set it). This is a did:webvh specific alternative to the deactivated flag, that ensures that the DIDDoc is automatically returned to the resolver. Not ideal, but we think it is better than a new query parameter.

My $0.02CDN for the DID Resolution spec is that it should be up to the DID Controller to decide what DIDDoc should be returned when the DID is deactivated -- either empty or an archival DIDDoc. The message that the DID is deactivated is received by the client of the resolver in either case via the metadata.

[peacekeeper]

If a DID is deactivated, it means it shouldn't be used anymore. So we thought the default behavior should be that DID documents are not returned, in order to minimize risks of mistakes or buggy implementations that fail to check the "deactivated" flag.

See previous discussions here: w3c/did-resolution#5

In what situations would you still want the DID document after the DID is deactivated? Maybe in such situations you don't really want to deactivate it, but do something else, like setting updateKeys to [] as you mentioned?

I don't really like the idea of leaving it up to the controller, I think the behavior of deactivated DIDs should be consistent across all DIDs and DID methods.

[swcurran]

Given the flexibility in using something with a full DID history like did:webvh, I had expected there would be more that a DID Controller could express in ending the use of a DID. Notably, I did not equate "revoked" (compromised -- don't use!!!) with "deactivated" (not being used any more). However, in looking at the discussion, there is no "revoked", and perhaps "deactive" is a synonym for revoked? I would like to see the expression of both to be possible.

I would also like to see the same distinction for keys/verification methods. It would be helpful in a DID with a history to be able to express that a key is in active use (being used for signing/decryption) for a period of time, deactivated (no longer used for signing/decrypting) and, when necessary, revoked (comprised -- don't trust anything signed with it!!). In did:webvh there is guidance right now that says, "grow the DIDDoc to include all keys not revoked", so that historical keys can be resolved and used for verification from the latest DIDDoc. But that is not practical if keys are rotated periodically -- e.g. monthly -- but the signatures signed with earlier values are still verifiable.

Further, I would like to have is a mechanism that allows resolving a fragment from ANY version of the DID, while also doing a check for later revocation of the key. Granted, this is a simple capability in did:webvh, while it is not obvious how it would be done with other DID methods. Despite that, there should still be a way to express that in DID Resolution.