Attachment Reference Exchange (ARex) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Security and Authorization

Page standards status: Trial-use

Security and Authorization

All systems conforming to this guide SHALL comply with the security and privacy requirements of the Da Vinci HRex implementation guide.

Client authentication

§arex-19 A content server SHALL support SMART Backend Services authorization using the client_credentials grant with asymmetric JWT client authentication.

§arex-20 A content server SHOULD support UDAP B2B where cross-organizational trust must be established without prior client registration.

Mutual TLS

§arex-21 A content server SHALL NOT require the establishment of a new mutual-TLS trust relationship as a condition of ARex participation.

§arex-22 Where a mutual-TLS channel is already established between two trading partners for other purposes, ARex traffic MAY traverse it as a transport-layer control. Such a channel SHALL NOT substitute for token-based authorization, and the requirements of arex-19 and arex-19 and

Certificate-based channel authentication is being wound down as a Da Vinci connectivity pattern. ARex therefore treats an existing mutual-TLS channel as an incidental property of a deployment, never as an authorization mechanism and never as something a participant must stand up. New deployments should not plan around it.

Authorization granularity

This is the part the existing stack does not solve, and it is where ARex contributes most.

Conventional SMART system scopes are the wrong shape for this problem. A grant of system/Binary.rs authorizes the holder to read every Binary on the server. A grant of system/DocumentReference.rs authorizes reading every document reference. Neither expresses the actual intent, which is: this client may retrieve the objects in this one manifest, arising from this one transaction, for this one patient, until this manifest expires.

§arex-23 A content server SHALL scope authorization to a single manifest. An access token valid for one manifest SHALL NOT grant retrieval of content indexed by any other manifest.

§arex-24 An authorization server SHOULD express manifest-scoped grants using RFC 9396 Rich Authorization Requests, with an authorization_details object carrying the manifest identifier and the reassociation identifiers from the manifest transaction context.

§arex-25 A content server SHALL verify that the authenticated client corresponds to the organization identified in the manifest transaction context requestingOrganization element. Successful authentication of some participant SHALL NOT be treated as authorization.

§arex-26 A content server SHALL reject retrieval requests received after the manifest expiry instant or after retraction, irrespective of token validity.

§arex-25 exists because the failure mode in a multi-party network is not an attacker — it is a correctly authenticated participant retrieving content published for someone else. Authentication answers who is asking. Only the transaction context answers whether they should have it.

Capability URLs

Bulk Data permits requiresAccessToken: false, in which unguessable URLs stand in for authorization. It is tempting because it is trivial to implement.

§arex-27 A content server SHOULD set requiresAccessToken to true. Capability-URL retrieval is a downgrade and SHALL be used only under an explicit trading partner agreement.

§arex-28 Where capability URLs are used, they SHALL be single-use, SHALL have a lifetime measured in minutes, and SHALL be bound to the requesting client or source network. Content URLs SHALL NOT carry patient identifiers, member identifiers, or transaction identifiers in the path or query string.

A capability URL is a bearer secret in a request line. It lands in proxy logs, gateway telemetry, and SIEM ingestion, and — decisively for this design — it cannot be revoked, which puts it in direct conflict with arex-14 through arex-14 through

Minimum necessary

§arex-29 A manifest SHALL index only content responsive to the specific request that occasioned it. A publisher SHALL NOT index a superset on the grounds that the receiver can choose what to retrieve.

Per-object addressing makes over-disclosure cheap and therefore likely. §arex-29 is the counterweight.