Stream: smart
Topic: is `jwks_uri` support required for SMART server?
Isaac Vetter (Jun 18 2020 at 19:47):
I interpret this section of the SMART Backend Services spec to say that:
- SMART servers SHALL support the JWKS format for receiving an app's public key,
- SHOULD support retrieving that key via a TLS-protected jwks_uri and
- MAY only support receiving that key through an out-of-band mechanism.
An alternative interpretation is that :
- SMART servers SHALL support retrieving the key through a jwks_url
- SMART servers SHALL support receiving the key through an out-of-band mechanism and
- apps SHOULD support jwks_url and MAY support communicating the key through an out-of-band mechanism
Which of the above two interpretations is (1) intended? and (2) supported by your SMART server?
Josh Mandel (Jun 18 2020 at 20:00):
(1) sounds like what we intended. But just to be sure I understand, the third bullet point you listed under your alternative interpretation seems to contradict the first bullet point, so I might be missing something.
Josh Mandel (Jun 18 2020 at 20:01):
Also, looks like your link is wrong -- do you want to update it so we're reading the same text?
Isaac Vetter (Jun 18 2020 at 21:18):
Josh - link fixed. Thanks.
the third bullet point you listed under your alternative interpretation seems to contradict the first bullet point, so I might be missing something.
The alternate interpretation is that a SMART server must support both methods, and use whichever is supported by the app. This phrase could suggest that interpretation:
If a client cannot host the JWK Set at a TLS-protected URL, it MAY supply the JWK Set directly to the FHIR server at registration time
Josh Mandel (Jun 18 2020 at 21:30):
Right, ok -- and reviewing now more carefully: the goal was to ensure that servers support both, and encourage clients to support jwks_uri based publication.
Josh Mandel (Jun 18 2020 at 21:30):
(Goal was to support clients that aren't online / capable of hosting keys, but as a less-common special case.)
Isaac Vetter (Jun 18 2020 at 21:49):
Ergh. Yet, the spec never says:
the FHIR server SHALL ...
Also, what's the case in which an app can securely host a redirect_uri, and not a jwks_uri?
Josh Mandel (Jun 18 2020 at 21:59):
There's no redirect_uri involved in Backend Services.
Yunwei Wang (Jun 23 2020 at 17:49):
That is also our interpretation that server SHALL support both and client SHOULD support jwks_url.
Isaac Vetter (Jun 24 2020 at 17:00):
thanks, Yunwei! Yet, that's explicitly not required by the spec. There is no requirement placed upon the FHIR server in this section. It's an assumption to turn this into a normative requirement.
Yunwei Wang (Jun 24 2020 at 20:58):
Yes. We had a discussion during the last Connectathon about those ambiguity in current Bulk Data IG for server requirement vs client requirement. I believe those will be addressed in Bulk Data 1.2 @Dan Gottlieb
Isaac Vetter (Jun 26 2020 at 17:54):
Thanks, Yunwei, Dan. Any idea yet of how this would be addressed? I'd like to understand the scenario in which a FHIR server should be disallowed from requiring an backend system to host a jwks_url, for example.
Dan Gottlieb (Jun 26 2020 at 18:47):
@Isaac Vetter @Yunwei Wang the clarifications around server requirements we discussed at the connectathon were for the export API kickoff request parameters, though that's not to say we shouldn't also consider updating the backend services spec if that's needed.
Dan Gottlieb (Jun 26 2020 at 18:47):
My recollection matches that of @Josh Mandel above - the intent was for servers to support both methods of registering public keys (jwks url and fixed jwks). While the first method is superior, I believe some clients devs were concerned about the need to maintain keys at an online location when the rest of the app is running behind a firewall and doesn't have any public facing elements.
Josh Mandel (Jul 02 2020 at 15:51):
Follow-up with clarifications at https://github.com/HL7/bulk-data/pull/79
Last updated: Apr 12 2022 at 19:14 UTC
