Stream: inferno
Topic: JWKS json
Sagar Sarvankar (Feb 16 2022 at 11:52):
Hello @Yunwei Wang
This is regarding jwks url. Please see screenshot.
jwks.png
Here, do we have to use the highlighted jwks url in our oauth provider? Although comment here says "if supported".
Even without using this URL, all the test cases pass (please check in the background of the screenshot).
Please let me know your thoughts
Thanks,
Sagar
Yunwei Wang (Feb 16 2022 at 14:11):
This is used for bulk data client registration. Please take a look of Bulk Data IG Registering a SMART Backend Service section. Using jwks url is strongly recommended by Bulk Data IG. If a server does not supporting using jwks url, the server can download the jwks and host it locally.
Sagar Sarvankar (Feb 16 2022 at 17:09):
Ok, thank you @Yunwei Wang . I will look into details about that one.
Sagar Sarvankar (Feb 17 2022 at 10:06):
Hello @Yunwei Wang ,
We configured the "JWK Set URL" (highlighted in our earlier screenshot), in our OAuth server. But while validating the token it fails, with the message "The JSON Web Token (JWT) cannot be validated because a signing key cannot be found".
Do we need to get the private key (asymmetric key pair) for https://inferno.healthit.gov/inferno/.well-known/jwks.json, that will be used by our OAuth server to sign the token?
Please help.
Thank you.
Yunwei Wang (Feb 17 2022 at 14:26):
You misunderstood the backend service workflow (http://hl7.org/fhir/uv/bulkdata/STU1.0.1/authorization/index.html). This private key is used by client to sign its client assertion. Auth server use the public key to verify the received client assertion. (http://hl7.org/fhir/uv/bulkdata/STU1.0.1/authorization/index.html#obtaining-an-access-token)
Sagar Sarvankar (Feb 19 2022 at 08:19):
Thank you @Yunwei Wang . I will look further in these links.
Sagar Sarvankar (Mar 01 2022 at 10:24):
Hello @Yunwei Wang
This is regarding 'ATT-10: 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 received by an application indicates'.
Does this talk about the URL highlighted in the screenshot here? infernojwks.png
Thank you.
Sagar
Sagar Sarvankar (Mar 09 2022 at 05:40):
Hello @James Threatte ,
I just wanted to check if @Yunwei Wang is on leave. I had posted this question few days back and I did not hear from @Yunwei Wang .
Also, if you are the right person, please let me know your thoughts on the question I posted.
Thank you,
Sagar
Michele Mottini (Mar 09 2022 at 14:32):
Yes, that is the URL they are talking about
Sagar Sarvankar (Mar 09 2022 at 14:41):
Ok. In ATT-10 it says the Health IT developer 'confirms' ..., here how do we confirm that this is the case? We have configured this URL in our app registration in oauth application.
How ATT-10 will be a pass? Is this demonstration step or attestation?
Regards,
Sagar
Michele Mottini (Mar 09 2022 at 15:03):
Modify what is returned by that URL, the server should then use the new values after the time specified by the cache-control header
Sagar Sarvankar (Mar 09 2022 at 17:13):
The URL https://inferno.healthit.gov/inferno/.well-known/jwks.json does not update the keys here and it has not updated in last more than 4-5 months.
Yunwei Wang (Mar 09 2022 at 18:03):
@Sagar Sarvankar Same as my answer in ATT-08 question. ATT tests is run by testing lab out of Inferno automatic testing. Testing lab uses Inferno to document the test result and observations. I have no knowledge about testing lab's procedure. This is based on ONC (g)(10) testing procedure
The health IT developer demonstrates that the Health IT Module does not cache a JWK Set received via a TLS-protected URL for longer than the “cache-control” header sent by an application indicates.
To answer second part of your question, https://inferno.healthit.gov/inferno/.well-known/jwks.json is the JWK set Inferno (as Bulk Data client) provides to the Health IT Module (as Bulk Data server) to verify the request payload. This test is about Bulk Data server SHALL NOT cache client provided JWK set indefinitely.
The analogy is that I MAY use the same password but server SHALL NOT store my credential on sever side indefinitely.
Robert Scanlon (Mar 09 2022 at 20:31):
In the case of Inferno, the fact that we do not rotate our keys is done to make it easier for users to run inferno behind their own firewalls, and so they do not need to expose a running instance of inferno somewhere addressable by the bulk data server. Since the Inferno client does not rotate its keys, we cannot test requirement for servers to refresh the keys automatically based on the cache-control header, and therefore we unfortunately require it to be checked outside of the Inferno tool.
Robert Scanlon (Mar 09 2022 at 20:40):
In this case, you could mock up a lightweight jwks endpoint for a fake client, show your system fetch those keys if you register a client that points to that URL for their keys, then change the keys served at hte endpoint (after whenever the cache header expires), and show those keys being retrieved by the system. It doesn't have to be the Inferno client, and the client doesn't actually have to work -- since you are just showing that limited requirement.
Robert Scanlon (Mar 09 2022 at 20:41):
Asking the test lab that are using for what they are expecting is a good idea though.
Sagar Sarvankar (Mar 10 2022 at 14:14):
Thank you, @Michele Mottini , @Yunwei Wang and @Robert Scanlon . I will look further into this.
Last updated: Apr 12 2022 at 19:14 UTC
