201809 Direct/Certificates Track

Return to September 2018 Proposals

Direct/Certificates

FHIR is a standard that defines a data format and API for health data exchange. X.509 Digital Certificates are widely used for client and server authentication in the internet ecosystem. Direct is an existing federal standard that is widely used in the USA for the exchange of healthcare data, backed by X.509 Certificates for digital signatures and encryption. Within the Direct community, DirectTrust provides scalable security and a trust framework through a single Federated Services Agreement, formal policies, accreditation, and a source of a bundle of trusted CA certificates. Because there is such expenditure involved in planning, setting up and maintaining trusted distribution networks, there is strong incentive to leverage existing networks as much as possible. Therefore, this track will explore two possible models of leveraging existing trust frameworks.

They are:

• Sending FHIR resources within a Direct Message as an attachment
• Utilizing Direct certificates with the FHIR RESTful API to enable trust relationships to scale

Pre-Requisites

For all levels of testing the required pre-requisite is the fundamental requirement that all FHIR servers SHALL support the capabilities interaction.

Track Administration

• Coordinator: Luis Maas, EMR Direct - lcmaas at emrdirect dot com
• Coordinator: Calvin Beebe, Mayo Clinic - cbeebe@mayo.edu

Expected participants

Participant	Scenario 1	Scenario 2
EMR Direct	x	A1(C/S) A2(C/S) B(C/S) C(C/S) D(C/S)
Inpriva	x	B(C) C(C)
MaxMD	x	A1(C/S) A2(C)
Janie Appleseed	x	.
MiHIN	.	A1 A2
MedAllies	x	A2(S) B C
Cozeva (off-site/remote)	x	A2(C)

For Scenario 1, list role (S=Sender R=Recipient) and (+) if IG for Context v1.1 compliant For Scenario 2, list use cases and role (C=Client S=Server) for participation

Scenarios

The following scenarios will be the primary focus within the track for this Connectathon:

1. Information Exchange using FHIR API via Direct Messaging ("FHIR via Direct" or "FHIR over Direct")
   1. Unsolicited Communication
   2. Solicited Communication
   3. FHIR Query
2. Utilizing X.509 certificates with the FHIR RESTful API to enable trust relationships to scale
   1. Client authentication & authorization for backend services (Use Case 2 B)
   2. Dynamic client registration (Use Case 2 D)

Definitions

• Source system is the system originally containing the data.
• Target System is the system ultimately receiving the data from the Source system.

Overview of Scenario 1

1. A simple use case that includes transmitting clinical information as FHIR resources or CDA documents from an edge system to another system with a FHIR API. See Sending FHIR resources in Direct Messages and previous connectathon.

• Note for discussion: Should CDA documents be out of scope for this FHIR connectathon? (unless we are talking about a DocumentReference resource with a CDA which would just be a FHIR resource)

1. A two-step use case that includes *[Note for discussion: @Lisa, this was your change... was a "second step" left out here?]
2. A patient or provider will query a medical record simply by sending a Direct Message to a Direct Address associated with a FHIR interface. ##TODO: whose responsibility is it to authorize the query? how are the identity assertions carried in the message validated and secured?

Scenario 1

Participants will need a Direct implementation that can send / receive Direct messages with context-enabled attachments as per the Implementation Guide for Expressing Context in Direct Messaging.

Roles

Message Recipient

Message Sender

Note: The recipient can either act as either the Source or the Target System depending on the workflow.

For Unsolicited Communication, System A (the Message Sender) pushes an information payload to System B (the Message Recipient).
For a Solicited Communication, System B (the Message Sender) pushes a request for information to System A (the Message Recipient). System A (the Message Sender) then pushes the requested payload back to System B (the Message Recipient).
For a FHIR Query, System A (the Message Sender) pushes a query to System B (the Message Recipient). Using System B's FHIR API, the query is executed to generate the response and System B (the Message Sender) sends that response back to System A (the Message Recipient).

• Note for discussion: what is difference between second and third items above?
• Note for discussion: Lisa to clarify use of CommunicationRequest vis-a-vis Direct over FHIR.

Steps for Direct Transfer

Sender as Target: Implementation Guide for Expressing Context in Direct Messaging

Sender as Source: Sending FHIR resources in Direct Messages.

Overview of Scenario 2

The following use cases will be backed by a trusted certificate ecosystem:

A. Mutual TLS client-server authentication/authorization
B. Authentication and Authorization JWTs for backend services
C. Authentication JWTs for authorization code grant
D. Dynamic client registration

Preconditions:

• The DirectTrust Interoperability Testing Bundle will be used as the trust bundle to establish trust for the connectathon.
• Each client will obtain or generate suitable certificates chaining to a certificate in this bundle. EMR Direct can provide test certificates to interested parties who do not operate their own CA.

Scenario 2 - Use Case A1 - Mutual TLS with FHIR Server (Full Read Access)

1. FHIR client presents a client certificate to Resource Server during SSL handshake in place of a conventional OAuth Bearer Access Token.
2. RS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the FHIR request is denied.
4. If certificate is valid and trusted, RS allows read access to resources.

Note: For purposes of this use case, successfully authenticated clients are authorized for full read access.

Comments: This authentication method is useful in applications where mutual TLS authentication is already well understood and organization- or individual-level credentials are availalbe for use in lieu of building in an OAuth flow where it didn't already exist. The most likely application of this use case would be automated backend services. Examples include both highly-privileged applications within an organization and cross-organizational queries. For this use case, Authorization and authentication are based on attributes such as identity and permitted uses (if expressed in the certificate) and trustworthiness of the Certification Authority.

Scenario 2 - Use Case A2 – Mutual TLS with OAuth Server

1. FHIR client presents a client certificate to Authentication Server token endpoint during SSL handshake in place of a client secret for client_credentials grant workflow.
2. AS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the request is denied.
4. If certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token to client.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: The benefits of this use case (as compared to A1) are that no changes to the RS are necessary to support mutual TLS as "standard" bearer tokens are used to access the RS. The modifications are limited to the AS to allow it to recognize and accept credentials from a trusted party.

Scenario 2 - Use Case B – Backend client authentication & authorization backed by trusted certificates

Authorization can be based on pre-existing relationships or as directed by a patient.

1. FHIR client presents signed JWT to AS token endpoint for client_credentials grant workflow, using the client_assertion and client_assertion_type parameters as per UDAP OAuth profile.
2. The AS validates the signature on the JWT, and validates the certificate backing the signature using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If signature is invalid, or certificate is invalid or untrusted, the request is denied.
4. If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: This use case lends itself well to a situation in which, as in A, there is no end user (e.g. automated backend services) or the end user does not have an account on the local system. The client_credential flow is used, but rather than authenticating the client app with a client secret, a JWT signed with the client app's private key is used instead. This allows for a network of trusted clients that can be recognized by an AS through minor enhancements to the AS and a standard set of requirements to participate in the network, helping to scale app deployment.

Scenario 2 - Use Case C – Client authentication for authorization code grant backed by trusted certificates

1. FHIR client presents a valid authorization code and a signed JWT to AS token endpoint for authorization_code grant workflow, using the client_assertion and client_assertion_type parameters as per UDAP OAuth profile.
2. The AS validates the signature on the JWT, and validates the certificate backing the signature using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
3. If signature is invalid, or certificate is invalid or untrusted, the request is denied.
4. If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
5. Client presents access token to RS when making FHIR requests in the usual manner.

Comments: This use case is included in order to demonstrate how certificate-based authentication and authorization code flow can be layered to achieve higher levels of security. This can be added-on to "standard" or SMART on FHIR authorization code flow where there is end user interaction, except that when the client app exchanges the authorization code for an access token, the client app authentication is performed as in B using a JWT signed with the app's private key instead of a client secret. The corresponding public key is validated by the AS to confirm that it is part of a trusted network of applications (at a minimum).

All of the above use cases eliminate the need for pairwise key exchange, and enhance security through the use of digital certificates rather than shared secrets by relying on trusted CAs and certificate validation instead.

Scenario 2 - Use Case D – Dynamic client registration backed by trusted certificates

One of the goals of this scenario will be to discuss candidate app registration profiles.

1. FHIR client includes signed software statement as part of registration request to AS registration endpoint.
2. The AS validates the signing certificate and determines whether it chains to anchor in DT Interop Testing Bundle.
3. If certificate is invalid or untrusted, the request is denied.
4. If certificate is valid and trusted, the AS processes the registration and issues a client_id.
5. Client uses this client_id for subsequent interactions with AS.

Help Links

Here are some links to assist implementers:

Results

FHIR Connectathon 19 will be held on September 29-30, 2018 in Baltimore. A link to download the report will be available after the conclusion of the Connectathon.

Governance Questions

This section will identify any governance issues or questions that arise from the Direct/Certificates Track

References

Direct, DirectTrust, and FHIR: A Value Proposition

Unified Data Access Profile (UDAP)