Stream: inferno
Topic: Caching JWK Set in FHIR Bulk API Workflow
Lakshmi Bhamidipati (Sep 28 2021 at 16:22):
Hello,
We are trying to understand how to demonstrate this Inferno test. It is part of "Visual and Inspection" tests.
"Health IT developer confirms the Health IT module does not cache the JWK Set received via a TLS-protected URL for longer than the cache-control header indicates."
Our authorization server is not caching the JWK Set that we get from Bulk Client. But I don't know how to demonstrate that to a proctor as part of Visual test. Any suggestions?
Thank you in advance.
Cooper Thompson (Sep 28 2021 at 18:24):
We're looking to issue two different calls to the token endpoint with JWTs signed using the same private key, where those calls are more than <cache control header> seconds apart, and then show that the JWKS URL was hit both times. If you are hosting the JWKS URL, you can show the web server logs that indicate it was hit when the product being certified attempted to do the JWT validation. You may want to control for other callers of the JWKS URL by checking the client IP.
Lakshmi Bhamidipati (Sep 28 2021 at 20:01):
Thank you. Are you also implementing the 2nd requirement in the authorization server? We are not caching the JWK Set. Is it required for certification? The does not specify "SHALL", so I was wondering if we need to do anything about it.
1) The authorization server SHALL NOT cache a JWKS for longer than the client’s cache-control header indicates.
2) The authorization server SHOULD cache a client’s JWK Set according to the client’s cache-control header; it doesn’t need to retrieve it anew every time.
Cooper Thompson (Sep 29 2021 at 13:13):
My read of the spec is that cache control handling is just recommended, not required. The requirement is that you don't cache for too long if you do cache.
Last updated: Apr 12 2022 at 19:14 UTC
