w3c
need TTL construct?
In DNS resolution, the source record includes TTL info that says how long an answer could/should be cached.
DID resolution has similar issues, but I'm not aware of a similar construct. Real-world usage of DIDs is going to need to not look up the latest DID Doc for a person every passing second. So how do we decide how often to do it? Is this an idea already covered in the DID spec, and I just missed it? If not, do we want it?
TTL on DNS doesn't have nearly as high a stakes as DID resolution. If you need to rotate a key for security reasons, it would be maddening to have told the world your DID Doc is cacheable for an hour... But no amount of decreased TTL (even down to 1 s) is going to drive latency entirely out of the system...
Is a TTL construct best done on the whole DID Doc, or on individual keys within them?
A few thoughts:
- TTLs for keys are interesting, but a new concept that many folks may have a difficult time grasping.
- TTLs for DID queries seem like something that should go in a resolver response AND could be application specific.
- TTLs for DID Documents may be something that could be annotated in the DID Document itself.
So, yes, seems like a feature that is interesting to have at many levels.... but we have no firm conclusion yet.
I had a RWoT paper with DID Resolution topics, caching is one of them: https://github.com/WebOfTrustInfo/rwot7/blob/master/topics-and-advance-readings/did-resolution-topics.md#caching
Quoting from that:
Caching behavior could be controlled by configuration of the DID Resolver, by additional input parameters of the DID Resolution process, or by contents of the DID Document (e.g. a "time-to-live" field), or by a combination of these options.
Our practical experience in developing our DID-based application was that caching was crucial to making the application useful. An example: proof requests that took 15 seconds without caching and less than a second with caching.
It will be challenging for an an Agent sending a message discovering that the public key they have cached has been rotated. In the scenario of an Agent encrypting/forwarding an async message over several hops to a receiving Agent, there might not be a way to inform the sender that the message handling failed because of a key rotation. This makes for a super-slow way to discover a rotation - basically a timeout on a never answered message. At least TTL would give the sender an idea of a poll rate to use for checking the ledger prior to a send. It will not be perfect, but could help.
TTL also enables an Agent's public key cache manager to (more) intelligently asynchronously check for key rotations for it's Agent. It could be done without TTL, but it would be helpful and reduce ledger polling.
There's a paper with some proposals for caching in DID Resolution, submitted to Rebooting-the-Web-of-Trust 11: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/caching-in-did-resolution.md
Was just researching some IPFS/PL specs and noticed that DNSLinks, an IPFS construct for bridging DNS resolution and IPFS resolution, has TTLs:
https://dnslink.dev/
And IPLD has a validity prop for similar/overlapping purposes:
https://docs.ipfs.tech/concepts/ipns/#how-ipns-works
apologies if that's off-topic, hope it helps!
This was discussed during the did meeting on 23 January 2025.
View the transcript
w3c/did-resolution#10
markus_sabadello: This is a bigger topic around caching. Could be a mix of TTL and other metadata parameters. Similar to DNS -- could follow that model, with a set of parameters.
… In the core spec.
<Zakim> JoeAndrieu, you wanted to say did-core, yes. controller-specified
manu: +1 for core spec. Multiple levels here. Speak to HTTP caching. Avoid discussions like TTL within verificationMethods. Can of worms there.
JoeAndrieu: Should be in DID Core, and that the DID Controller can set. Needs to be based on what the Controller sets -- not at the DID Method level.
swcurran +1 to DID Controller.
<JoeAndrieu> Could be an extension for did-core (not in did-core itself)
manu: DID Method spec would say how to expose/caching. DID Core would say how to express this.
<Zakim> JoeAndrieu, you wanted to say just a property
<manu> concerned about it being a property -- worried about security concerns there -- controllers might do something that is not supported by the DID Method (creating security vulns)
Wip: One issue to go in. Most others are extensions.
This was discussed during the did meeting on 23 January 2025.
Further discussion needed to determine how to address this issue.
This was discussed during the did meeting on 23 January 2025.
View the transcript
Transfered this issue to DID core per discussion in the January meeting
This was discussed during the #did meeting on 19 June 2025.
View the transcript
TTL construct required?
<ottomorac> w3c/
ottomorac: Okay moving on
ottomorac: This an issue migrated from DID Resolution to DID Core. It is related to caching of DID Resolution results and how this could be managed in the form of some Time To Live (TTL) contruct akin to what DNS does. There was agreement in January that this is something that should be set by the DID Controller, and not something defined by the
DID method.
… There was agreement that this is something that should be set by the DID controller not something defined by each DID method
1+
Wip: Yes we moved from DID resolution to DID core, do we agree that this is still relevant to be addressed?
<Zakim> JoeAndrieu, you wanted to suggest a property somewhere
JoeAndrieu: we might be able to address this if we convince ourselves that it is a security fix
… It should be the controller who sets this. They are the best party to state the TTL of their DID
… This suggests to me we want a property somewhere. Probably a top level property in the DID document
… Happy to talk with Simone in the security interest group to see if he would view it as a security concern
markus_sabadello: I think we should have this. Agree this should be set by the DID controller
… Wonder if this would be a property in the DID document. Or a DID Document metadata property in DID resolution result
… This feels like it could fit in to this set of metadata properties
… This is also related to a parameter we have, no-cache
… This is also in DID resolution
… I am in favour of having this feature, just not sure DID core is the right place
Wip: Yes moved this issue from DID resolution but still unsure if it belongs here....
JoeAndrieu: echo what Will says. In did:btc1 method we don't have a meta layer to store something like ttl.
… Not sure how we would get it in the metadata in some of the methods
markus_sabadello: I agree with that too. We have a good understanding of how to update DID documents across DID methods. We don't have a good understanding of how to update DID Document metadata
… From a theoretical standpoint metadata would be the right place. TTL describes the DID document not the subject
… Just because we have never had a way for these metadata properties to be set, doesnt mean it isnt the right way for it to be done
… However can see that putting it in the DID document is a more practical approach
This was discussed during the #did meeting on 26 June 2025.
View the transcript
need TTL construct? #896
<ottomorac> w3c/
ottomorac: previous meeting discussed adding a validity period
manu: best way is to add a TTL, but may be beyond current charter. We could add a 'heads-up' that a TTL is coming to the DID spec in the next major iteration. This pre-note could describe how it will work, etc. We could re-charter and enumerate the TTL as a coming features
<Zakim> manu, you wanted to note we have /3/ potential parallel recharterings :)
Ivan: not looking forward to having 2 items that could have different development lengths under the same charter. Can we try to minimize the administrative difficulties? Can we leave CID where it is and not move it into documents?
manu: we might even have unto 4 recharters. realizes this is difficult. However, there are several specs / projects going to market and we need to coordinate on standardization, so the multiple efforts / communities are in-line and don't conflict. Concerned that "standards divergence" would be a strong negative. CID belongs in this group.
Discussion around CBOR-LD and where it should go. This impacts VC barcode spec. It's going out to 10M's of people and will affect interoperability. Multiple DID methods vs one DID Method discussion, etc. Need to coordinate all of these topics before large scale deployments happen. It would be good to re-charter in order to handle all of these
items under the same umbrella
Ivan: maybe this is a discussion for later with all the key participants. Once we enumerate all the problem issues, lets's minimize the administrative impacts.
<manu> +1 to not doing more work than necessary to fix the worst of these issues.
ottomorac: add a 'block by recharter' label on this PR for now. Then we can address it in the future