FHIR Chat · Resolving UDAP consent_references

Stream: Da Vinci PDex

Topic: Resolving UDAP consent_references

Spencer Kathol (Nov 17 2021 at 19:44):

I'm trying to implement requirements here:
http://build.fhir.org/ig/HL7/davinci-ehrx/consent-oauth.html
Also relevant:
http://hl7.org/fhir/us/udap-security/2021Sep/b2b.html

We are expecting the consent_reference extension value in the token request to be a URL to a Consent resource. Per the UDAP B2B spec, it must be resolvable by the receiving party, but does not describe authorization requirements. Is there an expectation that the token-issuing party authenticate with the Consent resource owner in order to retrieve that information, and if so is there guidance on how that should be done?

Lloyd McKenzie (Nov 18 2021 at 00:23):

We hadn't really talked about that. Presumably a simple mutual TLS connection would suffice, but we should make that explicit. Can you submit a change request?

Josh Mandel (Nov 18 2021 at 02:40):

"simple"?

Spencer Kathol (Nov 18 2021 at 12:08):

Presumably in the future, there will be a central authority issuing client certificates - those will be used earlier in the process as well such as for the member match call. So these calls would use the same client cert... I think that should be OK. Jira ticket created: https://jira.hl7.org/browse/FHIR-34333

Lloyd McKenzie (Nov 18 2021 at 14:26):

'simple' as in only mTLS needed, not OAuth. Given that OAuth can require having a consent, we might end up in a situation where you need a consent to view the consent to... Also, mTLS is already mandatory for payer-to-payer unless both agree to do full UDAP. (Speaking of which, this would also need to be landed if doing full UDAP, so might not be a bad idea to raise a tracker against the UDAP spec too @Spencer Kathol)

Michele Mottini (Nov 18 2021 at 15:02):

The 'standard' FHIR way to do system-to-system authentication (so far) is SMART backend auth. Using mutual TLS would add a different way to do the same thing

Lloyd McKenzie (Nov 18 2021 at 15:16):

SMART backend requires the client to register with the server. mTLS means that so long as the systems can find each other in a trusted registry, they can talk to each other. mTLS is also already supported by payers, so it's an easier lift.

Michele Mottini (Nov 18 2021 at 15:18):

Is there a trusted registry? And no, not all payers already support mutual TLS: our system do support SMART backend but not mutual TLS for FHIR access

Lloyd McKenzie (Nov 18 2021 at 15:37):

@Robert Dieterle

Spencer Kathol (Nov 18 2021 at 17:35):

@Lloyd McKenzie I'll get another ticket submitted for UDAP today.

Spencer Kathol (Nov 18 2021 at 18:05):

My take on mTLS vs oAuth: this use case is embedded in a flow that does specify mTLS (currently). It would differ with other use cases that require SMART backend auth (I haven't implemented one of these yet). I believe the expectation per HRex is to have a central trusted registry but that hasn't been established yet afaik. In theory, the consent-collecting payer can derive the consent-requesting payer's identity from the client certificate, but many implementations terminate the TLS connection on a web server, and need to check identity in the application which complicates implementation for this approach. OAuth also introduces some hoops - such as per-payer OAuth client registration. I don't think I have a firm preference - just providing thoughts for discussion.

Spencer Kathol (Nov 18 2021 at 18:41):

One more related question - is there a place in the token request that we would expect to find the member ID other than the consent_reference object?

Spencer Kathol (Nov 18 2021 at 23:16):

https://jira.hl7.org/browse/FHIR-34342

Lloyd McKenzie (Nov 19 2021 at 04:29):

Spencer Kathol said: