Open kdenhartog opened 5 years ago
Thanks @kdenhartog for this very interesting question, there are several considerations here that have to do with fundamental web architecture:
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
Happy to discuss further pros and cons of these different approaches.
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.
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.