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?