DataRight+: Admission Control Baseline

Scope This document specifies methods for the following:

Participant management
Dynamic Client Registration
Transport level security

Terms & Definitions This specification utilises the various terms outlined within .

Ecosystem Policy: A policy document specific to the ecosystem presented by the Initiator. Within the Australian CDR this is referred to as a data recipients CDR Policy
Initiator Brand Identifier: A unique identifier for the brand name which is presented as the owner of the Initiator.
Initiator Entity Identifier: A unique identifier for the legal entity related to the Initiator.
Initiator Identifier: A unique identifier for the specific Initiator. SHALL NOT change throughout the life cycle of the Initiator.
Provider Registration Scope: A string value as defined by the relevant ecosystem profile.
SSA: Relates to a Software Statement Assertion

Introduction Describes the operation of an ecosystem and other mechanisms for controlling admission of participants. This specification describes a technical mechanism for a group of cooperating participants to establish a central source of truth of the permitted participants. In addition, it describes means and methods for participants to discover the existence of others, track the status of these participants and provide metadata of how to describe them to other participants. Note: This specification is heavily influenced by the original definition in the but avoids ecosystem specific statements in favour of relying on the respective ecosystem and to provide elaboration.

Ecosystem Authority The Ecosystem Authority is considered the primary arbiter of trust within the established ecosystem. In order to provide multiple layers of trust the Ecosystem Authority SHALL operate a combination of:

Ecosystem Certificate Authority ("Ecosystem CA"): An X.509 Public Key Infrastructure (PKI) compliant certificate authority
Ecosystem Directory ("Directory"): A set of APIs delivering metadata of participants
Ecosystem Signing Authority ("SSA Authority"): An X.509 JSON Web Signature () based signing authority

General Topology This specification outlines the requirements for the various components of a data sharing ecosystem. | Ecosystem CA <---------------------------+ |Verify +-------------------------+ Verify| | +-------------------------+ | | | Directory |-----------------+ | | +---------->+-------------------------<-------+ | | | | +-------------------------+ | | | | | +---------| SSA Authority |<---+ | | | | | | +-------------------------+ | | | | | Provider | | Software SSA JWKS | |Initiator|Trigger | | Metadata | | Statement Retrieval| |Metadata |Directory| | | | Assertion (SSA) | | |Refresh | | | | | | | | | | | | | | | | | | | | | | | | v | | v | +-----------------------+ +------------------------+ | | O------------------------O | | | Initiator | | Mutual TLS Channel | | Provider | | | incl SSA registration | | | | |<--O------------------------O->| | +-----------------------+ +------------------------+ ]]> The components provided in this diagram are further stipulated in the sections that follow.

Ecosystem CA The Ecosystem Certificate Authority:

SHALL issue certificates of at least 2048 bits
SHALL issue certificates using the RSA encryption suite
SHALL enforce the certificate profile as specified for each participant
SHALL NOT issue certificates exceeding 365 days
SHALL issue participant certificates via an Intermediate CA
SHALL manage, maintain and publish a Certificate Revocation List
SHALL support OCSP endpoints
SHALL manage and maintain a suitable Certificate Practice Statement

Directory The Directory is a combination of protected and generally available endpoints.

Authorisation Server The Ecosystem Directory:

SHALL make available an OAuth 2.0 authorisation server
SHALL authenticate the confidential client using private_key_jwt specified in section 9 of
SHALL support discovery, as defined in ;

The means by which participants acquires their relevant client_id is outside the scope of this document.

Resource Endpoints

Authenticated Directory Endpoints The Ecosystem Directory SHALL make available MTLS and Bearer token authenticated endpoint secured with a scope value of cdr:register (or other value specified by the Ecosystem Authority). As described further in the following authenticated endpoints SHALL be made available:

Resource Server Endpoint	`x-v`
`GET /cdr-register/v1/{industry}/data-holders/brands`	`2`

Public Directory Endpoints The Ecosystem Directory SHALL deliver the following unauthenticated and generally available endpoints, in accordance with :

Resource Server Endpoint	`x-v`
`GET /cdr-register/v1/{industry}/data-holders/brands/summary`	`1`
`GET /cdr-register/v1/{industry}/data-holders/status`	`1`
`GET /cdr-register/v1/{industry}/data-recipients/brands/software-products/status`	`2`
`GET /cdr-register/v1/{industry}/data-recipients/status`	`2`
`GET /cdr-register/v1/{industry}/data-recipients`	`3`

SSA Authority The SSA Authority issues JSON documents, signed using JWS, containing verified metadata sourced from the Ecosystem Authority. In addition to scope values defined within relevant resource sets the SSA Authority shall also include the Provider Registration Scope.

SSA Attributes The unsigned SSA is a JSON document containing the following attributes:

iss: REQUIRED Contains the iss (issuer) value of the SSA Authority. Unless specified otherwise this is set to cdr-register
iat: REQUIRED The time at which the request was issued by the SSA Authority, expressed as seconds since 1970-01-01T00:00:00Z
jti: REQUIRED A unique identifier for the document
legal_entity_id: OPTIONAL The Initiator Entity Identifier
legal_entity_name: OPTIONAL Human-readable name of the Initiator Entity
org_id: REQUIRED The Initiator Brand Identifier
org_name: REQUIRED Human-readable name of the Initiator Brand
client_name: REQUIRED Human-readable name of the Initiator
client_description: REQUIRED Human-readable description of the Initiator
client_uri: REQUIRED Website address of the Initiator
redirect_uris: REQUIRED List of URI for use as redirect_uri values in authorisation establishments
sector_identifier_uri: OPTIONAL URI to be used as an input to the production of Pseudonymous Identifiers as described in section 8 of
logo_uri: REQUIRED URI referencing a logo of the Initiator
tos_uri: OPTIONAL URI referencing the Terms of Service of the Initiator
policy_uri: OPTIONAL URI referencing the Ecosystem Policy of the Initiator
jwks_uri: REQUIRED URI referencing the JSON Web Key Set used by the Initiator for authentication purposes
revocation_uri: REQUIRED URI referencing the ICARE endpoint as specified within , if is supported by the Ecosystem
recipient_base_uri: REQUIRED Base URI to use for Initiator provider endpoints
software_id: REQUIRED The Initiator Identifier
software_roles: REQUIRED Role identifier of the Ecosystem. The only permitted value is currently data-recipient-software-product
scope: REQUIRED A space-separated list of scope values permitted to be accessed by the Initiator

Example A non-normative example of an unsigned SSA:

Authorisation Server The SSA Authority:

SHALL make available an OAuth 2.0 authorisation server
SHALL authenticate the confidential client using private_key_jwt specified in section 9 of
SHALL support discovery, as defined in OpenID Connect Discovery 1.0 ;

The means by which participants acquires their relevant client_id is outside the scope of this document.

Resource Endpoints

SSA Retrieval Endpoint The SSA Authority SHALL make available an endpoint for Initiators to download a compliant, time limited and cryptographically signed SSA which describes the Initiator themselves while asserting the authority of the SSA Authority. This endpoint will be available through an authenticated GET request to the path /cdr-register/v1/{industry}/data-recipients/brands/{initiatorBrandId}/software-products/{initiatorId}/ssa and SHALL return a JWS signed string of the document. Once provided to any participant, the Initiator ID contained within the software_id attribute, SHALL NOT change for the lifetime of the Initiator.

SSA Authority JWKS The SSA Authority SHALL make available the public signing keys, in JSON Web Key Set format, used for signing the SSA at the unauthenticated and generally available endpoint of GET /cdr-register/v1/jwks.

Provider In order to provide streamlined registration of Initiators the Provider must make available a service to facilitate registration of new OAuth 2.0 clients.

Authorisation Server The Provider authorisation server is required to perform a number of prescribed functions.

Dynamic Client Registration (DCR) The Provider authorisation server SHALL support . In addition, the Provider authorisation server:

SHALL require SSA documents as part of the Client Registration Request outlined in Section 3.1 of and;
SHALL validate provided SSA documents as per [SSA Attributes] and;
SHALL verify the signature of the SSA using the [SSA Authority JWKS] endpoint;
SHALL support client management endpoints described in Section 2 of ;
SHALL authenticate Initiators using private_key_jwt and an Ecosystem Authority defined scope value (typically cdr:registration);
SHALL require MTLS for all DCR related endpoints;
SHALL NOT permit multiple client registrations per Initiator Identifier;
SHALL supply client_id_issued_at in addition to the other REQUIRED fields outlined in section 3.2 ;
SHALL update Initiator statuses, at least every 5 minutes, by polling the GET /cdr-register/v1/{industry}/data-recipients/brands/software-products/status endpoint outlined in [Resource Endpoints]

Where there are overlapping attributes between the dynamic registration request and the provided SSA, the content of the SSA SHALL take precedence.

Initiator Initiators participating in the ecosystem:

SHALL support endpoint discovery as specified in
SHALL support dynamic registration in accordance with
SHALL retrieve a time-limited SSA, from the [SSA Retrieval Endpoint] and use it as the software_statement attribute for dynamic registration requests
SHALL support the client management provisions contained in Section 2

Implementation Considerations The use of OCSP Stapling within the CDR ecosystem is NOT RECOMMENDED. For MTLS endpoints, all participants MUST verify certificates used (client) and presented (server) are current and valid. This implicitly means all parties are required to utilise CRL or OCSP endpoints to maintain confidence in revocation status.