Caching in Solid-OIDC and protocol concerns

I have read the Solid-OIDC draft, and it was very readable, thank you for that!

My initial thought was the the general flow requires quite a lot of connections, and that we should look into optimizations. Since I'm more than average interested in caching as an approach, I started thinking what we could do on the protocol level for this.

AFAICS, Solid-OIDC does not make normative statements that ties it to HTTP, which is good, so this would also not belong in the Solid-OIDC document, but I'd like to air it.

There seems to be two types things that it seems could bear fruit in the short term:

One is the exp claim that appears both in the DPoP-bound Access Token and the OIDC ID Token. That seems to map well to a Cache-Control: max-age header in HTTP, so that it can be cached by normal HTTP caches in various positions on the Internet.

The other seems to be using conditional requests to see if it is possible to jump out of the flow in certain places. It seems harder though, but in point 7., if the public key hasn't changed, then perhaps it doesn't need to validate the signature. That's not a big saving, I guess. Do you see more opportunity for using conditional requests in the basic flow?

Start by reading the Solid-OIDC draft, especially the basic flow, the exp claims, and point 7 mentioned in the issue. Determine whether HTTP caching or conditional requests offer a concrete protocol-level optimization, and document a decided direction or rationale for not pursuing one.