201805 Direct/Certificates Track
Contents
- 1 Direct/Certificates
- 1.1 Pre-Requisites
- 1.2 Track Administration
- 1.3 Expected participants
- 1.4 Scenarios
- 1.5 Overview of Scenario 1
- 1.6 Overview of Scenario 2
- 1.6.1 Preconditions:
- 1.6.2 Scenario 2 - Use Case A1 (A1) Mutual TLS with FHIR Server (Full Read Access)
- 1.6.3 Scenario 2 - Use Case A2 (A2) – Mutual TLS with OAuth Server
- 1.6.4 Scenario 2 - Use Case B (B) – Backend client authentication & authorization backed by trusted certificates
- 1.6.5 Scenario 2 - Use Case C (C) – Client authentication for authorization code grant backed by trusted certificates
- 1.6.6 Scenario 2 - Use Case D (D) – Dynamic client registration backed by trusted certificates
- 1.7 Help Links
- 1.8 Results
- 1.9 Governance Questions
- 1.10 References
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
- EMR Direct
Scenarios
The following scenarios will be exercised within the track:
- Sending FHIR resources within a Direct Message as an attachment ("FHIR over Direct")
- Suggested workflow: encapsulated FHIR queries using Context IG
- Tasks will be documented after approval of use case
- Utilizing X.509 certificates with the FHIR RESTful API to enable trust relationships to scale
- Client authentication & authorization for backend services
- Client authentication for authorization code grants
- Dynamic client registration
Overview of Scenario 1
- A simple use case that includes transmitting clinical information via a workflow using FHIR resources. Specifically, FHIR Resources: (TBD) – and transport these as attachments. See - Sending FHIR resources in Direct Messages and previous connectathon.
- 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 - Use Case #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 EHR depending on the workflow.
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 connect-a-thon.
- 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 (A1) Mutual TLS with FHIR Server (Full Read Access)
- FHIR client presents a client certificate to Resource Server during SSL handshake in place of a conventional OAuth Bearer Access Token.
- RS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
- If certificate is invalid or untrusted, the FHIR request is denied.
- If certificate is valid and trusted, RS allows read access to resources.
Note: For purposes of this use case, successfully authenticated client are authorized for full read access.
Scenario 2 - Use Case A2 (A2) – Mutual TLS with OAuth Server
- 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.
- AS validates certificate using standard PKI processes and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
- If certificate is invalid or untrusted, the request is denied.
- If certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token to client.
- Client presents access token to RS when making FHIR requests in the usual manner.
Scenario 2 - Use Case B (B) – Backend client authentication & authorization backed by trusted certificates
Authorization can be based on pre-existing relationships or as directed by a patient.
- 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.
- 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.
- If signature is invalid, or certificate is invalid or untrusted, the request is denied.
- If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
- Client presents access token to RS when making FHIR requests in the usual manner.
Scenario 2 - Use Case C (C) – Client authentication for authorization code grant backed by trusted certificates
- 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.
- 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.
- If signature is invalid, or certificate is invalid or untrusted, the request is denied.
- If signature is valid, and certificate is valid and trusted, the AS grants a conventional OAuth Bearer Access Token.
- Client presents access token to RS when making FHIR requests in the usual manner.
Scenario 2 - Use Case D (D) – Dynamic client registration backed by trusted certificates
One of the goals of this scenario will be to evaluate candidate app registration profiles.
- FHIR client presents public key and certificate to AS registration endpoint as part of registration request.
- The AS validates the certificate and determines whether client certificate chains to anchor in DT Interop Testing Bundle.
- If certificate is invalid or untrusted, the request is denied.
- If certificate is valid and trusted, the AS processes the registration and issues a client_id.
- Client uses client_id and its public key for subsequent interactions with AS.
Help Links
Here are some links to assist implementers:
Results
FHIR Connectathon 18 will be held on May 12-13, 2018 in Koln. 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