DID-URL uniqueness across time

[kdenhartog]

While discussing with @peacekeeper DID-urls as a mechanism to refer to a key in a DID Document we came across an interesting question. Does a DID URL need to be unique across the entire history of the document?

In many cases this would be a helpful aspect to support for DIDComms. Particularly what this would help avoid is if a message was encrypted with DID#key1 at epoch 1, then it could be uniquely identified for the lifetime of the DID Document. This means that if DID#key1 were rotated to DID#key2 at epoch 2, then at epoch 3 DID#key1 or DID#key2 could be dereferenced.

The alternative to this would be that DID#key2 overrides DID#key1 at epoch 2. Then when dereferencing the key at Epoch 3 a time must also be specified.

[peacekeeper]

Thanks @kdenhartog for this very interesting question, there are several considerations here that have to do with fundamental web architecture:

• Note that there is a proposal for a DID URL matrix parameter that allows you to specify a version number or timestamp of a DID Document, in order to resolve previous versions: Add "version-id" and "version-time" DID URL matrix parameters. w3c-ccg/did-spec#194. With this proposal, you could reference keys (or service endpoints, or any other parts of a DID Document) at an arbitrary point in time, e.g.:

did:btcr:xz35-jzv2-qqs2-9wjt;version-time=1557005485#key-1
did:btcr:xz35-jzv2-qqs2-9wjt;version-time=1551020938#key-1

• I think the question you ask is whether after you rotate a key, should it have a different DID URL, e.g. #keys-2 instead of #keys-1? From a web architecture point of view, this translates to the question whether a key rotation operation generates a new "resource", or just updates the existing "resource". I think this can be argued both ways.

• If we decide a rotated key is a new resource and should therefore have a new unique DID URL, then another question is whether the outdated key should be kept in the DID Document and marked as revoked (see https://w3c-ccg.github.io/did-spec/#public-keys), or whether it should be removed from the DID Document.

• One idea that has also been mentioned at some point is that the DID URL fragments for keys should contain hashes of those keys, e.g.:

did:btcr:xz35-jzv2-qqs2-9wjt#key-65d80b0974c396c726ce860871f98f0c

• There are also DID method-specific considerations. Some DID methods may allow the DID controller arbitrary choice of DID URL fragments, whereas others may have method-specific logic for fragments that can't be overridden.

Happy to discuss further pros and cons of these different approaches.

[kdenhartog]

Interesting points that are brought up here. It seems every suggestion would handle the concern that originally brought this to my attention (DIDComm including a DID-url to a specific key). My preference would be toward the key hashing method or the version-time method.

In my initial opinion version time would be preferred because it could specifically reference to a block on chain or to a time which would make did resolution easier I would think. I'll need to speak with some people/read more about the other ideas to see if this opinion holds after exploring the other ideas more. Thanks for posting this.