Stream: FHIR at Scale Taskforce (FAST): Security
Topic: Consumer scenario for connectathon
Josh Mandel (Dec 02 2021 at 20:23):
From track plans in Jan (https://confluence.hl7.org/pages/viewpage.action?pageId=130482809):
- Trusted Dynamic Registration & JWT-Based Authentication (Consumer Facing)
Precondition: Client has user-level credentials for FHIR server and client's UDAP certificate is trusted
Success Criteria: Client app successfully registers, authenticates, and obtains FHIR data leveraging a trusted certificate. Client should validate server metadata per UDAP Server Metadata profile.
I'm confused by the language. Does the precondition mean that the client is asking for the user's credentials, and not doing an OAuth cdoe flow the way http://build.fhir.org/ig/HL7/fhir-udap-security-ig/consumer.html documents? Or is this language just a bit confusing?
Josh Mandel (Dec 05 2021 at 18:52):
Also for this track, when working with an endorsement: if the client doesn't participate in mutual TLS, how does the endorsement's sub get populated? https://www.udap.org/udap-certifications-and-endorsements.html doesn't list the sub as optional, but the following suggests it's not required:
To facilitate key rollover, binding using the sub claim URI is preferable to binding to a specific key.
@Luis Maas
Josh Mandel (Dec 05 2021 at 18:53):
And when presenting an endorsement at registration time, how is a client expected to demonstrate possession of one (or more) keys in the JWKS? The requirement is specified but I don't see any mechanism specified.
Josh Mandel (Dec 06 2021 at 22:13):
Also @Luis Maas I think I understand http://build.fhir.org/ig/HL7/fhir-udap-security-ig/registration.html#request-body but I don't understand what the sections above ("Client Credentials" and "Authorization Code") are about. Are they copy/paste mistakes, or can you help me understand what they mean?
Luis Maas (Dec 06 2021 at 22:41):
@Josh Mandel mutual TLS is not required for certifications; the client would use a URI from the subjectAltName extension of their signing cert to populate sub. The sub field is required. Binding to a specific key is done by including the jwks claim in the certification; the comment re: rollover means that including the jwks is not preferred in certifications and endorsements; rather, binding of the client to the certification or endorsement JWT is done by confirming sub matches a URI entry in the subjectAltName extension of the client's certificate and that the certificate is from a trusted issuer.
Luis Maas (Dec 06 2021 at 22:47):
@Josh Mandel yes, the three introductory paragraphs one the page you noted ("Client Credentials" and "Authorization Code") are slated to be moved out of this section. Just haven't made the change yet ;)
Luis Maas (Dec 06 2021 at 22:57):
re: presenting the endorsement, the client still supplies a signed software_statement in the POST body to the registration endpoint; if the endorsement contains a jwks value, then the client must use one of the corresponding private key to sign the software_statement or the endorsement will not be accepted by the OAuth server processing the registration. Similarly, all JWTs used in subsequent token requests must also be signed using one of the corresponding private keys. Note that this is in addition to validating the endorsement sub matches one of the URIs in the client certificate's subjectAltName extension.
Luis Maas (Dec 06 2021 at 23:10):
sorry for answering out of order...
re:
I'm confused by the language. Does the precondition mean that the client is asking for the user's credentials, and not doing an OAuth cdoe flow the way http://build.fhir.org/ig/HL7/fhir-udap-security-ig/consumer.html documents? Or is this language just a bit confusing?
Yes the language is confusing: It should say "User has user-level credentials..."
Josh Mandel (Dec 07 2021 at 00:21):
Thanks for the responses! In your view is there a role for self signed certs on a software statement? (Looking at per device registration scenarios which I know are listed as future scoped, but wanted to build some prototypes. My take is that per device keys would be strictly better than a public client registration, and could work with self signed software statements and a locked down endorsement JWT )
Josh Mandel (Dec 07 2021 at 14:33):
if the endorsement contains a
jwksvalue, then the client must use one of the corresponding private key to sign the software_statement
Ah, so "one of" is all that's intended. Ok, that's unclear.
Josh Mandel (Dec 14 2021 at 19:42):
See https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Trusted.20app.20instance.20registration.20and.20UDAP with notes on this topic, given our deep dive last week.
Last updated: Apr 12 2022 at 19:14 UTC
