w3c
DID-URL uniqueness across time
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.
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: https://github.com/w3c-ccg/did-spec/pull/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-2instead 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.
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.
In our DID WG call today we considered that this issue might have been overtaken by events, meaning that we already understand that uses of DIDs must take into account the time when the container for the DID was created. However, a question that came out of this was whether the root DID document needs an expiration property.
@burnburn — According to the W3C Calendar, the 2024-11-07 DID WG call was cancelled. Minimally, some subsequent comment should provide a link to the minutes of such conversation as was had.
I'm guessing we needed two separate events in order to handle the different call time on the first Thursday of the month, which is always our APAC-friendly call. See https://www.w3.org/events/meetings/b52feb5b-1018-453b-bb3d-d00c54cb3cd0/20241107T200000/ If you subscribe to the DIDWG calendar ( https://www.w3.org/groups/wg/did/calendar/?past=1&tf=0) you will see this event there.
This was also clearly confirmed in the agenda email sent out: https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0000.html
All that said, I am still sad to hear that you missed the call.
The minutes were taken but have not yet been processed and uploaded by Pierre-Antoine, who I'm sure will get to it as soon as he can.
-- dan
On Fri, Nov 8, 2024 at 3:41 PM Ted Thibodeau Jr @.***> wrote:
@burnburn https://github.com/burnburn — According to the W3C Calendar, the 2024-11-07 DID WG call was cancelled https://www.w3.org/events/meetings/7ced2998-7e23-49e2-be67-c3a929291607/20241107T080000/. Minimally, some subsequent comment should provide a link to the minutes of such conversation as was had.
— Reply to this email directly, view it on GitHub https://github.com/w3c/did-resolution/issues/37#issuecomment-2465714654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI54U5HIZ4K2UKDHMIT2BDZ7UOYZAVCNFSM6AAAAABRMPDHM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVG4YTINRVGQ . You are receiving this because you were mentioned.Message ID: @.***>
This was discussed during the did meeting on 08 November 2024.
View the transcript
w3c/did-resolution#37
burn: that link will show issues in the proper order.
… subtopics that reference issues like that will automatically post an update to that issue.
joeandrieu: I think we've moved on from this issue (it was posted five years ago).
… it is understood that at different points in time, your keys may have rotated. So resolvers need to understand to ask for the DID document current at a particular point in time or a particular version.
burn: yes, that's a helpful resolution to an issue. In the WebRTC WG, they called it "overtaken by events".
… however Joe also commented that it would be helpful to make sure it was clear in the spec.
<burn> drummond: if the spec doesn't make Markus' point clearly, it should
<burn> ack
denkeni: key rotation has always been a key part of the spec, so is this a question of whether key state should be specified by a DID method.
… he mentioned that Christopher Allen said once that "everything should expire". This applies to verifiable credentials. Have we ever considered that for DIDs? How does that apply to key rotations?
… this topic needs more high-level discussions.
burn: this is about explicit versioning?
denkeni: should you rotate keys or have to change the DID URL?
jennieM: from the start of this WG, this was a topic: what happens when a DID method goes away completely.
… we can see that in the minutes from the meeting of Sept 23rd at TPAC.
<JennieM> https://
<burn> drummond: this gets deep fast.
<burn> ... the question of the relationship of the state of a did document to a DID (what we used to call a naked DID, without the URL bits) and potentially to a DID URL which could include identifiers of a state. Whether its a version, a time, or something else. This is a complex question.
<burn> ... the original spec is fairly clear about when to use each method.
joeandrieu: this expiry question is a good one. I lean against having some state indicator in the raw DID itself.
… but verification properties should have an expiration. And if they don't, I'd like to understand.
burn: there is more to this issue that was in the initial response that he had been typing in this issue.
joeandrieu: can anyone check to see if verification methods have an expiration property.
drummond: we should clarify whether verification methods have an expiration property?
joeandrieu: if so, that could resolve this issue. If not, then that may open a larger question.
… it also raises the larger question of whether the root DID document might need an expiration property.
drummond: yes, I don't remember that ever coming up, but that could indeed make sense.
<denkeni> https://
denken: I added a link to the section about key and signature expiration in DID Core.
… it raises the question of whether this is a DID Core issue, a DID Resolution issue, or a DID method issue.
… this is relevant because we're going to start DID method standardization.
… it could also be important for distinguishing between DID methods.
… some DID methods may want to take responsibility for this control and some won't.
burn: I prefer this speed of conversation. Makes for better deliberation.
drummond: +1
This was discussed during the #did meeting on 27 February 2025.
View the transcript
w3c/did-resolution#37
DID-URL uniqueness across time...
wip: Kyle is asking about the keys in the document...
manu: Yes we should allow it.... it is not necesarrily good practice...
manu: we may want to warn people...
manu: in our implementation we just use the public key identifier value as the identifier for the key....
manu: works to guarantee this over time...
<JoeAndrieu> +1 to recommending using keys rather than restricting values
markus_sabadello: I also think we should allow it....
markus_sabadello: yes, you should able to change keys... again not best practice...
markus_sabadello: yes this in general is a feature.... and add a warning
wip: ok yes we can mark as pending closed... and open an issue in did-core along with some security considerations....
manu: before we move on... lets not bury in security considerations...
manu: it should clearly warn people about the implications...
wip: Yes that make sense, but the challenge is also have the CID spec....
manu: Yes that is true....
manu: we should probably have this group take over the CID spec once its published....
