need TTL construct?

[dhh1128]

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?

[msporny]

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.

[peacekeeper]

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.

[swcurran]

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.

[peacekeeper]

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

[bumblefudge]

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!