Consider adding resolution options that go beyond DID Resolution that make use of the did:webvh Verifiable History

[swcurran]

Raised for discussion:

A powerful capability of did:webvh is being able to easily access all of the history of a did:webvh DID -- especially all of the keys that were used by the DID. This allows signing something with a reference to a specific verificationMethod key (e.g. <did>#<keyId>) and it being very efficient to find that key in the did:webvh history. However, the DID Resolution spec does not make it easy to reference such a past fragment, requiring that only fragments from the current DID Document be returned -- meaning that to resolve an old key, you have to know and use a combination of query parameters (e.g. versionId and/or versionTime) plus the <keyId> -- <did>?versionTime=<time>#<keyId>. That relies on the versionTime being sufficient to find the key.

The did:webvh "workaround" for this is described here on the did:webvh info site. But that is really space and time inefficient, replicates the verificationMethod fragments over and over, and balloons the size of both the DID Log and the DIDDocs returned. Ugly!

It would be better if the resolution process of a fragment returned the fragment from any version of the DID (current or past), and provided metadata that provided additional details about the fragment and when it is/was active. There would need to be some constraints on the fragment, and I propose the following:

• The full fragment must only appear on initial use, and the result returned is the one from first use.
• A reference to the fragment (without details) may appear in subsequent DIDDocs -- indicating that the fragment is still "active"
• Once a fragment is not included in a DIDDoc versions, it is considered on longer active. It is ignored in any subsequent DIDDoc versions.
• On resolution of the fragment, metadata would provide an timeActivated (versionTime of first Log Entry with the fragment) and timeDeactivated (versionTime of the first subsequent Log Entry without the fragment -- if any). A status might be helpful -- current, rotated or something like that.

Further, we need a way for the DID Controller to notify resolvers when keys referenced in a DID have been compromised and should not ever be trusted. To do so:

• A new DIDDoc attributed, perhaps keysCompromised is added, an array of <keyId>s that have been determined to be compromised. Whenever a DIDDoc version or fragment is resolved that contains a key in the list, the Metadata would include the keysCompromised list. Or likely better, return an error.

I think that both of these capabilities should be in the DID Resolution spec, but am happy to add them to did:webvh for "experimentation", until they can be added to the DID Resolution spec. I understand that not all DID Methods can (efficiently) support these capabilities.