CH EPR FHIR (R4)
4.0.1-ballot-2 - ballot Switzerland flag

This page is part of the CH EPR FHIR (R4) (v4.0.1-ballot-2: DSTU 4 Ballot 3) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Get Authorization Server Metadata [ITI-103]

Scope

At launch time an App may connect to the Authorization Server to retrieve the configuration data. The Authorization Server responds with the configuration data and the Authorization Server endpoint the App shall direct the User Agent to.

Actor Roles

Actor: Authorization Client or Resource Server
Role: Sends a request to the Authorization Server to retrieve configuration data and the server endpoint to redirect the User Agent to.
Actor: Authorization Server
Role: Responds with the FHIR Server configuration data.

Referenced Standards

  1. IHE ITI Technical Framework Supplement Internet User Authorization (IUA) Revision 2.2
  2. SMART Application Launch Framework Implementation Guide Release 2.1.0
  3. Well-Known Uniform Resource Identifiers

Messages

Interaction Diagram for [ITI-103]Authorization ClientorResource ServerAuthorization ServerAuthorization Server Metadata RequestAuthorization Server Metadata Response

Authorization Server Metadata Request

Trigger Events

An EPR App (portal, primary system or SMART on FHIR App) wants to retrieve the Authorization Server metadata (e.g. , authorization endpoint locations, key material required for signature validation, or other relevant authorization data).

Message Semantics

The Authorization Client or Resource Server performs an HTTP GET request to the Authorization Server well-known endpoint URL for the smart configuration. The request SHALL neither use parameter nor body data.

Expected Actions

The Authorization Client or Resource Server MAY read the URL of the IUA Authorization Server and redirect the User Agent to the Authorization Server.

Message Example
GET {URL-Server}/.well-known/smart-configuration  HTTP/1.1

Authorization Server Metadata Response

Message Semantics

The Authorization Server SHALL respond with an HTTP response conveying a JSON formatted object as HTTP body element. The JSON object SHALL convey the following attributes:

Attribute Optionality Reference Description
authorization_endpoint R SMART on FHIR / IUA URL to the IUA Authorization Server endpoint.
token_endpoint R SMART on FHIR / IUA Authorization Server's Authorization token end-point location.
token_endpoint_auth_methods_supported O SMART on FHIR Client authentication methods supported by the token endpoint. When provided, this list SHALL include "client_secret_basic" and SHOULD include “client_secret_post”.
registration_endpoint O SMART on FHIR URL to the OAuth2 dynamic registration endpoint for this FHIR server.
scopes_supported O SMART on FHIR / IUA Recommended: Supported scopes.
response_types_supported R SMART on FHIR / IUA Supported OAuth 2.1 response_type values.
grant_types_supported R IUA SHALL include “authorization_code” and "urn:ietf:params:oauth:grant-type:jwt-bearer".
management_endpoint O SMART on FHIR URL an end-user can view which applications currently have access to data and can make adjustments to these access rights.
revocation_endpoint O SMART on FHIR Recommended: URL to a server’s revoke endpoint that can be used to revoke a token.
capabilities R SMART on FHIR SMART capabilities (e.g., single-sign-on or launch-standalone) that the server supports.
issuer R IUA The Authorization Server's issuer identifier.
jwks_uri R IUA URL of the Authorization Server's JWK Set [RFC7517, Section 5] document.
access_token_format O IUA Array of JSON strings defining the format of the access token as provided by the Authorization Server. The array SHALL contain a single string with value “urn:ietf:params:oauth:token-type:jwt”.
Attributes of the Get metadata transaction
Expected Actions

There are no further requirements beyond those defined in the SMART on FHIR specification.

Message Example
{
    "authorization_endpoint": "https://ehr.example.com/auth/authorize",
    "token_endpoint": "https://ehr.example.com/auth/token",
    "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"],
    "registration_endpoint": "https://ehr.example.com/auth/register",
    "scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.*", "purpose_of_use=*", "subject_role=*", "person_id=*", "principal=*", "principal_id=*", "organization=*",  "organization=_id*", "access_token_format=*"],
    "response_types_supported": ["code", "id_token"],
    "grant_types_supported": ["client_credentials", "authorization_code", "urn:ietf:params:oauth:grant-type:jwt-bearer"],
    "management_endpoint": "https://ehr.example.com/user/manage",
    "revocation_endpoint": "https://ehr.example.com/user/revoke",
    "capabilities": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"],
    "issuer": ["launch-ehr", "client-public", "client-confidential-symmetric", "context-ehr-patient", "sso-openid-connect"],
    "jwks_uri": "https://ehr.example.com/auth/jws",
    "access_token_format": ["urn:ietf:params:oauth:token-type:jwt"]
    }

CapabilityStatement Resource

There are no CapabilityStatement resources defined for this transaction.

Security Consideration

The actors SHALL support the traceparent header handling, as defined in Appendix: Trace Context.

Security Audit Considerations

There is no audit event required for this transaction.