What's the lifetime of a did:plcresolution?

[snarfed]

Hi all! I'm currently working on did:plc resolution for the ATProto client side. How long can I assume a did:plc's DID Doc is valid? I haven't found anything relevant in https://atproto.com/specs/did-plc or https://github.com/bluesky-social/did-method-plc . Should I just use the 72h rotation key rewrite window, and eventually any custom window as mentioned in https://github.com/bluesky-social/did-method-plc#possible-future-changes ?

I looked at https://www.w3.org/TR/did-core/ briefly too, and found a bit of discussion, below, but nothing specific.

Thanks in advance!

https://www.w3.org/TR/did-core/#persistence :

...it is vital that systems relying on the persistence of an identifier over time regularly check to ensure that the identifier is, in fact, still under the control of the intended party.

https://www.w3.org/TR/did-core/#key-and-signature-expiration :

...it is with supporting software such as DID resolvers and verification libraries that requesting parties validate that cryptographic material were not expired at the time they were used. Requesting parties might employ their own expiration policies in addition to inputs into their verification processes. For example, some requesting parties might accept authentications from five minutes in the past, while others with access to high precision time sources might require authentications to be time stamped within the last 500 milliseconds.

[bnewbold]

This is a great question, and something we have been discussing internally as well.

The scope of external info includes did:plc, did:web, and handle resolution.

There might be different desired lifetime (TTL) after resolution for cases of: errors during resolution (eg, HTTP timeout, or can't connect to PLC directory); not-found resolution (DNS NXDOMAIN, HTTP 404); invalid handle (not bi-directional confirmation); successful resolution; "local" vs. "remote" accounts (eg, if you are a service provider with control over some aspects, like handle hosting); did:plc deletion (tombstone) status after any recovery window has expired (aka, DID is then permanently deleted).

In some circumstances you might want to "bust the cache" or "try harder": if you get a repo event with an invalid signature, should probably try to flush DID cache (containing repo signing key).

For larger scale services, it might be worth scraping the did:plc directory audit log keep up to date with all identity changes, instead of regularly polling all identities.

For services subscribing to the firehose, depending on the firehose provider might trust it to notice identity changes and send events on the firehose (eg, handle changes). We might need to change the event stream schema and responsibilities/semantics of proviutders (BGS) to solidify this. The idea would be that downstream services can still confirm the new identity info out-of-band, but would keep identities cached for a long time (months?) otherwise.

On Bluesky services (at medium-large scale), we had been caching identities indefinitely, but are in the process of moving to refreshing periodically. Note that this requires a constant stream of resolution requests, depending on scale.

To throw out some rough numbers to start the conversation somewhere concrete, I'd throw out caching successful identity resolution for about 24 hours, and be willing to retry failed resolutions on demand after a few minutes.

[snarfed]

Thanks! Glad you all are thinking along all these lines, this all makes sense. Some of these have existing support for expiration, cache control, etc built into them, notably DNS and HTTP requests, but the rest don't. Fortunately we don't have to come up with exhaustive answers for all of them right away, starting with a few heuristics and expanding them as necessary could be ok.

And yeah I was thinking about ingesting the whole PLC directory too. Re-downloading periodically would work to start. Maybe eventually consider a PLC directory firehose too, as an optimization? Not urgent, obviously.

[bnewbold]

Yeah, a PLC firehose would make sense. We want to keep did:plc fairly distinct and simple for now. If BGS consumes from did:plc and emits updates as part of the firehose, that mostly solves it. Maybe a special firehose coming out of BGS with just identity updates? That way BGS also has a chance to attempt handle validation.

[snarfed]

Ooh totally! I'd love that. Honestly independent handle validation was waaaaay down my list of priorities, like maybe never going to happen low 😆

[DavidBuchanan314]

^ This is more LLM generated spam (and contradicts recommendations from the real answer earlier in the thread)