Security for Scalable Registration, Authentication, and Authorization, published by HL7 International / Security. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-udap-security-ig/ and changes regularly. See the Directory of published versions

Home

Introduction

This implementation guide describes how to extend OAuth 2.0 using UDAP workflows for both consumer-facing apps that implement the authorization code flow, and business-to-business (B2B) apps that implement the client credentials flow or authorization code flow. This guide covers automating the client application registration process and increasing security using asymmetric cryptographic keys bound to digital certificates to authenticate ecosystem participants. This guide also provides a grammar for communicating metadata critical to healthcare information exchange.

This Guide is divided into several pages which are listed at the top of each page in the menu bar.

• Home: The home page provides the introduction and background for this project, and general requirements that apply to all workflows described in this guide.
• Discovery: This page describes how clients can discover server support for the workflows described in this guide.
• Registration: This page describes workflows for dynamic registration of client applications.
• Consumer-Facing: This page provides detailed guidance for authorization and authentication of consumer-facing apps.
• Business-to-Business: This page provides detailed guidance for authorization and authentication of B2B apps.
• Tiered OAuth for User Authentication: This page provides detailed guidance for user authentication.
• General Requirements: This page provides general requirements applicable to multiple authorization and authentication workflows.

Guidance regarding the use of this IG with the SMART App Launch Framework can be found in Section 7.5.

Trust Community Checklist

A trust community is a group of member entities that has come together to support one or more interoperability use cases between its members. Typical examples of trust communities include health information networks and interoperability frameworks (e.g. a network of networks). Trust communities may be defined by geography (e.g. regional, national, international) or any other criteria (e.g. affiliated healthcare organizations, users of a common technology platform, support of specific use cases required by regulation, etc.).

This guide provides a technical framework to securely scale FHIR transactions within a trust community using X.509 certificates as the basis of community trust, including both consumer-facing and B2B workflows. It is expected that trust communities will establish agreements and policies to address certain community-specific parameters in this guide, as well as non-technical aspects necessary for interoperability, e.g. criteria for community membership, data-sharing agreements, certificate issuance policies, etc.

Additional topics to be addressed by trust communities adopting this guide are listed below:

1. Assignment of unique URIs to servers for use in certificates and in the iss and sub claims of signed metadata elements (see Section 2.3).
2. URI used to identify the community in metadata requests (see Section 2.4).
3. Assignment of unique URIs to client applications for use in certificates and in the iss and sub claims of software statements (see Section 3.1).
4. Assignment of unique URIs to organizational requestors for use in a B2B Authorization Extension Object (see organization_id in Section 5.2.1.1).
5. Minimum set of scopes that servers must support (see scopes_supported in Section 2.2).
6. Allowed values for requestor roles in a B2B Authorization Extension Object (see subject_role in Section 5.2.1.1).
7. Permitted purposes of use for which data may be requested in a B2B Authorization Extension Object (see purpose_of_use in Section 5.2.1.1).
8. Consent and authorization policies that may be asserted in a B2B Authorization Extension Object and supporting documentation (see consent_policy and consent_reference in Section 5.2.1.1).
9. Time synchronization between community participants.
10. PKI policies including policies for certificate issuance and distribution.
11. Other community policies or conditions that an actor may need to meet before exchanging data with community participants or with other trust communities. Examples include community legal agreements, certificate policies, policies regarding what claims an actor has the authority to assert, and other community requirements relating to the specific use cases, client types and/or grant types supported by the community.