Caching did:web documents, OAuth/OpenID metadata and StatusList2021

[reinkrul]

An OAuth2 authz code flow with 2 OpenID4VP causes AS metadata to be retrieved 4 times and the DID document to be resolved 8 times. Since these are relatively static resources they could be cached quite easily, improving UX (faster flows) and reducing traffic (and access logs).

Relates to:

• Support caching of did:web resolutions #2420
• Use caching headers when fetching/publishing StatusList2021Credentials #3028
• Decide/implement whether metadata needs to be cached #2034

Suggestion

• Use HTTP/1.1 Cache Control headers to communicate max-age to the client reading the resource. If parties want to override this, they can do this in their reverse proxy.
• Don't solve caching in the DID resolver and IAM client, but do this in the HTTP clients used. There are several Go libraries for this (e.g. https://github.com/pquerna/cachecontrol).
  • Since you don't want unbound in-memory caches, you might want a cache per resource type?

Issues:

• Do we want to prevent clustering issues: e.g. node A having a different version of a resource than node B? Although if the resource server gracefully migrates the endpoint, this shouldn't be an issue?

did:web documents

The did:web method designers somewhat agree that regular HTTP cache control headers are a good direction: w3c-ccg/did-method-web#40

When DID documents are used to store services, long caching times (e.g., a day) could cause unpractical staleness, so caching should be relatively short in that case. That said, parties changing endpoints should always do this by graceful migration: the old endpoint should stay available for a reasonable amount of time. On the other hand, caching DID documents for a minute already reduces the number of resolutions from 8 to 1 for the flow described above.

Suggestion: max-age of 5 minutes by default

OAuth2/OpenID Metadata

The same applies to metadata endpoints.

Suggestion: max-age of 5 minutes by default

StatusList2021

Max. cache time is influenced by the governance, on how fast credentials should be revoked. eIDAS requires CAs to revoke certificates within 4 hours. But as status list is a small resource (since it uses the bit string), it can be refreshed more often than that.

Suggestion: max-age of 5 minutes by default