Server-side caching of DID documents

[reinkrul]

A DID resolve always queries the database, since they're not cached server-side. Although it's a relatively cheap operation, it's an unauthenticated API call (which literally anyone can do), so there's a small DoS risk in there. This can be mitigated by caching the DID document server-side, either by building it into the Nuts node (meh) or having a reverse proxy cache the DID documents.

Note that the Nuts node's did:web resolver already cached DID documents.

Update: this also applies to the Discovery Service.

[gerardsn]

I prefer the second option, so using caching headers that a reverse proxy can act on. I believe these headers are already set. Maybe we can provide an example of how to do this in nginx in the documentation?

[woutslakhorst]

We also require some sort of internal caching. We should cache the unmarshalled document shortly so all internal DID resolves don't hit the DB AND don't require a json.Unmarshall. Even if it's for 10 seconds. This should be an in-memory local cache only (not clustered).

So a layered cache would be best:

• for the client by a reverse proxy
• internal, in-memory for a couple of seconds (equal to the timeout (10 seconds))?

[reinkrul]

We also have to be able to mark the cache as stale if you change the DID document. Otherwise, you wouldn't observe the changes in it after making a change (e.g. adding a key).