Distributed cache invalidation

Short time listener, first time caller to the HTTP WG list.

I see draft-ietf-httpbis-cache-groups, I’ve seen “no-vary-search cache poisoning" in the archives from Julian Reschke, and tangentially related posts about "cache-control vs new header field" and "strange browser cache quirks”… I’m sorta interested in draft-nottingham-http-invalidation-01 or the discussion to be had around it.

I’m ignorant to and seeking guidance on how agents front-ended by HTTP artifacts (agent cards, tool manifests, JWKS etc) cached across gateways they don’t own might wish to revoke or invalidate (ideally with a verifiable authorization artifact like a transparency log’s inclusion proof etc) stale data.


  1.
Is this a bad idea?
  2.
If it’s not a bad idea, certainly there’s a security implication?
  3.
If either the above, should it even be possible for a content owner to be able to do this?

~ Nic Williams