Security for Scalable Registration, Authentication, and Authorization
3.0.0-ballot - STU 3 Ballot

Security for Scalable Registration, Authentication, and Authorization - Downloaded Version 3.0.0-ballot See the Directory of published versions

## Home

Official URL: http://hl7.org/fhir/uv/fast-security/ImplementationGuide/hl7.fhir.uv.fast-security | Version: 3.0.0-ballot
IG Standards status: Trial-use | Maturity Level: 4 | Computable Name: FASTSecurity

This ballot is moving a US realm publication to International. The content of the IG is not changing from the US STU2 (December 2025) publication, but the title, id, canonical URL, and some of the metadata are being updated to reflect the new realm. The ballot is inviting any comments or feedback from the community. Please review the changes carefully and provide any feedback you may have.

### 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.