NAV Navbar
Examples

Introduction

Consumer Data Right

The Australian Government is introducing a Consumer Data Right (CDR) to give consumers more control over their data.
The CDR will be rolled out sector-by-sector across the economy, starting with the banking sector.
The Government has announced that the energy and telecommunications sectors will follow banking.

Further information on the CDR is available on the Treasury website:
https://treasury.gov.au/consumer-data-right

ACCC's Role

The ACCC will be lead regulator for the CDR regime, and will have roles and functions that include:

Further information on the ACCC’s role in the CDR is available on the ACCC’s website:
https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0

Data Standards Body

A Data Standards Body (DSB) has been established to develop technical standards to implement the CDR. The work of the DSB is being delivered by a team within Data61, overseen by interim DSB Chair Mr Andrew Stevens, and with industry and consumer advice provided by an Advisory Committee.

Further information on the DSB is available on its website:
https://consumerdatastandards.org.au

Consultation outline

The ACCC is using this website as a tool to consult on aspects of the design and implementation of the register of CDR participants (the CDR Register). The ACCC is seeking comments from interested stakeholders.

Consultation rules of engagement

The ACCC intends to conduct public consultation on the CDR Register. Questions or comments that participants might ask us via email or private message are likely to be questions or comments other participants have as well. Our answers will be of interest to everyone. There are likely to be experiences and lessons everybody working in this ecosystem can learn from. Having these conversations transparently helps reduce duplication, resolve issues faster and keep everyone up to date with the conversation.

We ask that all contributors to the CDR Register GitHub comply with the GitHub Community Forum Code of Conduct.

In addition, it would be appreciated if the following rules are adhered to when commenting or contributing:

The ACCC will be actively monitoring and reviewing any comments/responses which are provided, however will not be responding to individual comments. Depending on the number of responses/comments we get, we will assess what the most efficient and effective way to engage with the community is, noting that we want this to be a collaborative effort.

CDR Register on GitHub

Feedback sought

To guide responses and comments, we are seeking input which will assist us in ensuring that the Register designs meets the needs of the overarching CDR ecosystem. The focus should be on validating the designs, and providing any necessary context and reasoning.

Consumer Data Right Register

The ACCC will perform the role of the CDR Registrar. The CDR Registrar will have the function of maintaining the Register of Accredited Persons (the Register) who have been granted accreditation by the ACCC in its capacity as Data Recipient Accreditor. Accredited persons become Accredited Data Recipients upon receipt of CDR data.

The Register will also include information about Data Holders. Information about Accredited Data Recipients and Data Holders recorded in the Register will be made available to the public in accordance with the CDR rules. Additional information held in the Register will be available to accredited data recipients and data holders.

Ecosystem Entities

CDR consumer

A consumer, as defined in the CDR rules, who is able to a make a request for disclosure of CDR data to themselves or to an accredited data recipient

Data Holder

A person who holds designated CDR data and is required by the CDR rules to disclose product and consumer data

Data Holder Brand

An individual name that is used to collectively identify CDR data sets held by a Data Holder. This will be aligned to, and may or may not be the same as a business name that is registered to the Legal Entity who is the Data Holder

Data Holders would typically have one or more brands within the Consumer Data Right

Accredited Data Recipient

A person that has been granted accreditation by the ACCC and is able to collect, and receives, CDR data about a CDR consumer from a data holder with the consent of the consumer

Accredited Data Recipient Brand

An individual name that is used to collectively identify a set of products and/or services offered by an Accredited Data Recipient. This will be aligned to, and may or may not be the same as a business name that is registered to the Legal Entity who is the Accredited Data Recipient

Data Recipients would typically have one or more brands within the Consumer Data Right

Software Product

Accredited Data Recipients create Software Products which provide consumers the ability to get insight into their data held by Data Holders

Accredited Data Recipients would typically have one or more products within the Consumer Data Right

Entity Relationship Diagram

The following is a logical model of the entities exposed to participants through the Register APIs

Identifiers

The identifiers outlined in the Ecosystem entities diagram map to Client Registration and APIs defined in this documentation.

Identifier Mapping
legalEntityId Identifier in LegalEntityDetail schema returned as part of GetDataHolderBrands API
Identifier in RegisterDataRecipient schema returned as part of GetDataRecipients API
dataHolderBrandId Identifier in RegisterDataHolderBrands schema returned as part of GetDataHolderBrands API
dataRecipientBrandId org_id claim as defined in the SSA Definition
Identifier in DataRecipientsBrandMetaData schema returned as part of GetDataRecipients API
softwareProductId software_id claim as defined in the SSA Definition
iss claim as defined in the Registration Request

Ecosystem Component Diagram

The following is a high level overview of the CDR ecosystem outlining the components and API endpoints each participant within the ecosystem will be expected to implement.

Note that ADRs are expected to have one or more Software Products consuming CDR data.

Fullcomponentdiagram

Data Holder

Component Responsibility
Identity Provider Provides identity services to the Data Holder’s platform for identifying Accredited Data Recipients and the CDR Register
Authorisation and Consent Manager Provides authorisation functionality to the consumer including consent withdrawal propagation to the relevant Accredited Data Recipients
Secrets Manager Provides key management for issuance/rotation of JWKs & certificates and storing of authorisations
Standards Platform Exposes banking, consumer and product data to Accredited Data Recipients as per the Consumer Data Standards Banking APIs and Common APIs
MetaData Cache Cache of discovered Accredited Data Recipients and their associated Software Products within the CDR ecosystem. Caching rules and logic are described at: Metadata Cache Management
Metrics Facilitates Get Metrics requests from the ACCC Register as per the Consumer Data Standards Get Metrics
Authorisation Dashboard The Dashboard provided to the consumer to view their current sharing authorisations with the Data Holder. The dashboard also provides the functionality to explicitly withdraw these authorisations with this Data Holder. Details can be found in the CX Guidelines
API Responsibility
Banking APIs APIs exposing banking data as per the Consumer Data Standards Banking APIs
Common APIs APIs exposing common data as per the Consumer Data Standards Common APIs
InfoSec APIs APIs exposing endpoints to facilitate the InfoSec profile as per the Consumer Data Standards Endpoints
Registration APIs APIs exposing dynamic registration endpoints as described at Dynamic Client Registration
Admin APIs APIs exposing metrics data as per the Consumer Data Standards Admin APIs

Accredited Data Recipient

Component Responsibility
Software Application(s) One or more consumer facing applications provided by the Accredited Data Recipient
Application Platform Accredited Data Recipient’s application platform which requests consumer and product data from Data Holders as per the Consumer Data Standards Banking APIs and Common APIs
Consent Manager Provides consent functionality to the consumer including consent withdrawal propagation to the relevant Data Holder
Secrets Manager Provides key management for issuance/rotation of JWKS & certificates and storing of consents
MetaData Cache Cache of discovered Data Holders within the CDR ecosystem. Caching rules and logic are described at:
Metadata Cache Management
Consent Dashboard The Dashboard provided to the consumer to view the consents given to this Accredited Data Recipient to collect and use CDR data. The Dashboard also provides the functionality to explicitly withdraw these consents with this Accredited Data Recipient. Details can be found in the CX Guidelines
API Responsibility
InfoSec API API exposing the revocation endpoint to facilitate bi-directional consent revocation, as per the Consumer Data Standards Endpoints

Register

The Register exposed APIs to satisfy the following main requirements:

1. Facilitates discovery of Data Holders and their endpoint details within the CDR regime
2. Facilitates discovery of Data Recipient details within the CDR regime
3. Provides SSAs to facilitate Dynamic Client Registration
4. Provides public JWKS to assert SSAs are trusted by the CDR Register
5. Collect ecosystem metrics from participating Data Holders as per the Consumer Data Standards Get Metrics

API Responsibility
Discovery APIs (DH & DR) APIs exposing the discovery of Data Holder Brands and Data Recipients within the CDR regime.
APIs are described at: GetDataHolderBrands, GetDataRecipients
Status APIs APIs exposing the statuses of Accredited Data Recipients and associated Software Products within the CDR regime.
APIs are described at: GetDataRecipientsStatus, GetSoftwareProductsStatus
SSA API API exposing the retrieval of SSAs used by Accredited Data Recipients to register with Data Holders within the CDR regime.
API is described at: GetSoftwareStatementAssertion
InfoSec APIs API exposing endpoints to facilitate OIDC as well as exposing Register public JWKS used to verify the signature of SSA payloads. Further details are available at: Dynamic Client Registration

Certificate Authority

The CDR Register will be using DigiCert as the ACCC endorsed Certificate Authority. Further details on certificate management can be found at: Certificate Management

Client Registration

Dynamic Client Registration

Accredited Data Recipient Software Products within the Consumer Data Right will dynamically register with one or more Data Holders, to obtain client credentials used to retrieve consumer data on behalf of a consumer.

The CDR Registration model follows standard [RFC7591] and is derived from Open Banking UK model with design input from the ABA

Pre-Requisites: Prior to Client Registration, the registering Data Recipient must be accredited and the associated Software Product must be configured within the CDR Register

Software Statement Assertion (SSA) Design

A Software Statement is defined in [RFC7591] as: A digitally signed JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software

Within the Consumer Data Right, the CDR Register will issue Software Statements for Accredited Data Recipient Software Products

The trust relationship the authorization server has with the issuer of the software statement is to be used as an input to the evaluation of whether the registration request is accepted.

A software statement is presented by Accredited Data Recipient’s Software Product to Data Holder’s authorisation server as part of a client registration request.

An SSA will be issued for each active Software Product and is retrievable using the CDR Register GetSoftwareStatementAssertion API

Namespacing

The design will conform to [RFC7591] and will not use the software namespace convention as used in the Open Banking UK Dynamic Registration Standard

Digital Signing Algorithm

Conforming to [FAPI-RW], SSAs will be signed on the CDR Register using PS256

SSA Lifetime

Method Lifetime (mins) Notes
Manually distributed 30
Obtain via API 10 The intention here is this should be sufficient time to
batch register with all relevant Data Holders

SSA Definition

Example SSA:

eyJhbGciOiJQUzI1NiIsImtpZCI6ImI4ZmFjZjJmZjM5NDQ0Zjc4MWUwYmU1ZGI0YjE0ZjE2IiwidHlwIjoiSldUIn0.ew0KICAiaXNzIjogImNkci1yZWdpc3RlciIsDQogICJpYXQiOiAxNTcxODA4MTY3LA0KICAiZXhwIjogMjE0NzQ4MzY0NiwNCiAgImp0aSI6ICIzYmMyMDVhMWViYzk0M2ZiYjYyNGIxNGZjYjI0MTE5NiIsDQogICJvcmdfaWQiOiAiM0IwQjBBN0ItM0U3Qi00QTJDLTk0OTctRTM1N0E3MUQwN0M4IiwNCiAgIm9yZ19uYW1lIjogIk1vY2sgQ29tcGFueSBJbmMuIiwNCiAgImNsaWVudF9uYW1lIjogIk1vY2sgU29mdHdhcmUiLA0KICAiY2xpZW50X2Rlc2NyaXB0aW9uIjogIkEgbW9jayBzb2Z0d2FyZSBwcm9kdWN0IGZvciB0ZXN0aW5nIFNTQSIsDQogICJjbGllbnRfdXJpIjogImh0dHBzOi8vd3d3Lm1vY2tjb21wYW55LmNvbS5hdSIsDQogICJyZWRpcmVjdF91cmlzIjogWw0KICAgICJodHRwczovL3d3dy5tb2NrY29tcGFueS5jb20uYXUvcmVkaXJlY3RzL3JlZGlyZWN0MSIsDQogICAgImh0dHBzOi8vd3d3Lm1vY2tjb21wYW55LmNvbS5hdS9yZWRpcmVjdHMvcmVkaXJlY3QyIg0KICBdLA0KICAibG9nb191cmkiOiAiaHR0cHM6Ly93d3cubW9ja2NvbXBhbnkuY29tLmF1L2xvZ29zL2xvZ28xLnBuZyIsDQogICJ0b3NfdXJpIjogImh0dHBzOi8vd3d3Lm1vY2tjb21wYW55LmNvbS5hdS90b3MuaHRtbCIsDQogICJwb2xpY3lfdXJpIjogImh0dHBzOi8vd3d3Lm1vY2tjb21wYW55LmNvbS5hdS9wb2xpY3kuaHRtbCIsDQogICJqd2tzX3VyaSI6ICJodHRwczovL3d3dy5tb2NrY29tcGFueS5jb20uYXUvandrcyIsDQogICJyZXZvY2F0aW9uX3VyaSI6ICJodHRwczovL3d3dy5tb2NrY29tcGFueS5jb20uYXUvcmV2b2NhdGlvbiIsDQogICJzb2Z0d2FyZV9pZCI6ICI3NDBDMzY4Ri1FQ0Y5LTREMjktQTJFQS0wNTE0QTY2QjBDREUiLA0KICAic29mdHdhcmVfcm9sZXMiOiAiZGF0YS1yZWNpcGllbnQtc29mdHdhcmUtcHJvZHVjdCIsDQogICJzY29wZSI6ICJiYW5rOmFjY291bnRzLmJhc2ljOnJlYWQgYmFuazphY2NvdW50cy5kZXRhaWw6cmVhZCBiYW5rOnRyYW5zYWN0aW9uczpyZWFkIGJhbms6cGF5ZWVzOnJlYWQgYmFuazpyZWd1bGFyX3BheW1lbnRzOnJlYWQgY29tbW9uOmN1c3RvbWVyLmJhc2ljOnJlYWQgY29tbW9uOmN1c3RvbWVyLmRldGFpbDpyZWFkIg0KfQ.ZNKe8aBHcsZ_OfdP0GvUa0AHrjcoC0Coky4jQHrPsRoG3YMcS2XG9JtyB5zq-AMOQoaib1Ijx1m7B-JOEbVcnNJcLUZeVEIwnP8hRssAnGjWwaYGUAiY-DEFUsuXqpQWgyIOFz84W-FaHFcqpOSGxjGmjICZU9S1Pl4o8b5poA_kJ2n_wdiOBUG4xl3uXqzK_vstcGXbAubFyLhjOxhc_rqONO2NCtpyCwj83Zqi7Ve_A27-ty5N0AQa2xYWvjDt_Xh8xcxRI_ih7_sStvDTTy3gtyX5bAdXsDsweCcvN0d2vOCpm6-dnr8D1fXDTnlT3x2uQ0XAysWr6wU4mAZFVA

Associated JWKS:

{
  "keys": [
    {
      "kid": "b8facf2ff39444f781e0be5db4b14f16",
      "kty": "RSA",
      "key_ops": [
        "sign",
        "verify"
      ],
      "n": "s0zGoaOEJE8HDfHjWtO0xLXtuPcwio8BEoj0-uu9kxxDIF7jH0jb06EwoPkb83BET59x6C0TtRfc_I5ZDksQKRClWXzbazqi62M5YhCgwyB-S09PJb8P1GfQBYyK346nLKARHbFJ1t1SHARcVFJA_8NeHfQn_0fyEc55R3GGNDL3YQtjEoTb-LMR-KpcPB2BpyDuie-jk-3f1t0EfvnkVp-6co1_KTXrbwuYtH31YBZLgU4JeZEJLTnGdMKmJppZ9SnyrBB461hMmw0HJHJj6uZJSiP2onmvlrUezv1T3NM3HOE7WHxlps9MUJj3vcpea-O6n5JBX8emTduLuLuKuw",
      "e": "AQAB"
    }
  ]
}

Decoded SSA

{
  "alg": "PS256",
  "kid": "b8facf2ff39444f781e0be5db4b14f16",
  "typ": "JWT"
}

{
  "iss": "cdr-register",
  "iat": 1571808167,
  "exp": 2147483646,
  "jti": "3bc205a1ebc943fbb624b14fcb241196",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "client_name": "Mock Software",
  "client_description": "A mock software product for testing SSA",
  "client_uri": "https://www.mockcompany.com.au",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "software_roles": "data-recipient-software-product",
  "scope":
        "bank:accounts.basic:read
         bank:accounts.detail:read
         bank:transactions:read
         bank:payees:read
         bank:regular_payments:read
         common:customer.basic:read
         common:customer.detail:read
         cdr:registration"
}

Client Metadata Required Modifiable Description
iss Required MUST contain an iss (issuer) claim denoting the party attesting to the claims in the software statement
value: "cdr-register"
iat Required Issued at time claim
exp Required Expiration Time claim
jti Required JWT ID claim. A unique identifier for the token, used to prevent reuse of the token.
org_id Required A unique identifier string assigned by the CDR Register that identifies the Accredited Data Recipient Brand
org_name Required Human-readable string name of the Accredited Data Recipient Brand to be presented to the end user during authorization
client_name Required Human-readable string name of the software product to be presented to the end-user during authorization
client_description Required Human-readable string name of the software product description to be presented to the end user during authorization
client_uri Required URL string of a web page providing information about the client
redirect_uris Required Array of redirection URI strings for use in redirect-based flows
logo_uri Required URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval
tos_uri Optional URL string that points to a human-readable terms of service document for the Software Product
policy_uri Optional URL string that points to a human-readable policy document for the Software Product
jwks_uri Required URL string referencing the client's JSON Web Key (JWK) Set [RFC7517] document, which contains the client's public keys
revocation_uri Required URI string that references the location of the Software Product consent revocation endpoint as perConsumer Data Standards Endpoints
software_id Required String representing a unique identifier assigned by the ACCC Register and used by registration endpoints to identify the software product to be dynamically registered.

The software_id will remain the same across multiple updates or versions of the same piece of software.
The software_id should be used as the primary external identifier for the client to prevent duplicate client registrations
software_roles Required String containing a role of the software in the CDR Regime. Initially the only value used with be “data-recipient-software-product”
scope Required String containing a space-separated list of scope values that the client can use when requesting access tokens.
These CDS scope values are defined at: Authorisation Scopes
The DCR scope value is defined at: Client Registration Management

Client Registration Considerations

The CDR Register will only issue SSAs for Software Products which are currently in the Active state

Sector Identifiers

As per the Consumer Data Standards, the Pairwise Pseudonym Identifier (PPD) as described in section 8 of [OIDC], will use the host component of the redirect_uris as the sector identifier. This introduces a constraint that the redirect_uris must all contain the same hostname.

The CDR Register registration design will introduce support for the sector_identifier_uri in a future release. Adoption would require Data Holder implementation and updates to Software Product registrations moving from redirect_uris to utilising the sector_identifier_uri

Logos

Logos will be incorporated within the SSA to ensure there is consistency between the logos published on the Public Register and those passed to Data Holders as part of Registration

CDR Register SSA Signing

Registration Request using JWT

Example Request

HTTP/1.1 POST /register
Content-Type: application/jwt
Accept: application/json

## Non-normative Decoded JWT
{
   "alg":"PS256",
   "typ":"JWT",
   "kid":"12456"
}
{
   "iss":"CDR Software Product ID",
   "iat":"1571808167",
   "exp":2147483646,
   "jti":"37747cd1c10545699f754adf28b73e31",
   "aud":"https://secure.api.dataholder.com",
   "redirect_uris":[
      "https://www.mockcompany.com.au/redirects/redirect1",
      "https://www.mockcompany.com.au/redirects/redirect2"
   ],
   "token_endpoint_auth_signing_alg":"PS256",
   "token_endpoint_auth_method":"private_key_jwt",
   "grant_types":[
      "client_credentials",
      "authorization_code",
      "refresh_token",
      "urn:ietf:params:oauth:grant-type:jwt-bearer"
   ],
   "response_types":["code id_token"],
   "application_type":"web",
   "id_token_signed_response_alg":"PS256",
   "id_token_encrypted_response_alg":"RSA-OAEP",
   "id_token_encrypted_response_enc:"A256GCM",
   "request_object_signing_alg":"PS256",
   "software_statement":…
}
{
  "signature":...
}

To register a Software Product with a Data Holder, the Accredited Data Recipient sends an HTTP POST to the Data Holder registration endpoint.

The request MUST be presented in the format of a [RFC7519] compliant JWT. The request MUST use the HTTP POST method, using the application/jwt content type.

The JWT MUST be signed using algorithms specified in section 8.6 of [FAPI-RW]

The client registration request MUST contain the following claims in the JWT payload unless designated as Optional

Claim Required Description
iss Required Contains the identifier for the ADR Software Product as defined in the CDR Register
iat Required Issued at time claim
exp Required Expiration Time claim
jti Required JWT ID claim. A unique identifier for the token, used to prevent reuse of the token.
aud Required Data Holder auth server URI
redirect_uris Optional Array of redirection URI strings for use in redirect-based flows. Only required if the claim overwrites the list of values in the software statement. If used, redirect_uris MUST match or be a subset of the redirect_uris as defined in the SSA
token_endpoint_auth_signing_alg Required The algorithm used for signing the JWT
token_endpoint_auth_method Required The requested authentication method for the token endpoint. The only supported method will be private_key_jwt
grant_types Required Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. Supported values: [client_credentials, authorization_code, refresh_token, urn:ietf:params:oauth:grant-type:jwtbearer]
response_types Required value: [code id_token]
application_type Optional Kind of the application. The only supported application type will be web
id_token_signed_response_alg Required Algorithm with which an id_token is to be signed

Supported values as constrained by [FAPI-RW]
id_token_encrypted_response_alg Required JWE alg algorithm with which an id_token is to be encrypted
id_token_encrypted_response_enc Required JWE enc algorithm with which an id_token is to be encrypted
request_object_signing_alg Optional Algorithm which the ADR expects to sign the request object if a request object will be part of the authorization request sent to the Data Holder

Supported values as constrained by [FAPI-RW]
software_statement Required Software statement assertion issued by the CDR Register

ID Token Algorithm Selection Considerations

ID Token algorithms currently being applied in the ecosystem include:

Claim Values
id_token_encrypted_response_alg RSA-OAEP
RSA-OAEP-256
id_token_encrypted_response_enc A256GCM
A128CBC-HS256

Registration Validation

Validation and use of the JWT and the claims described above MUST be performed in accordance with JWT

Validation of the SSA software_id and the associated software status is not required as the SSA will have been issued and signed by the CDR Register

Each software_id issued by the CDR Register should only be registered on each Data Holder Brand IDP once. Multiple registrations per software_id are NOT permitted

Registration Response

Example Created Response

HTTP/1.1 201 Created
Content-Type: application/json

{
  "client_id": "2cfefa98-7d4a-4bcb-95da-47063b84d410",
  "client_id_issued_at": 1574398823,
  "redirect_uris": [
     "https://www.mockcompany.com.au/redirects/redirect1",
     "https://www.mockcompany.com.au/redirects/redirect2"
   ],
   "token_endpoint_auth_signing_alg":"PS256",
   "token_endpoint_auth_method":"private_key_jwt",
   "grant_types":[
      "client_credentials",
      "authorization_code",
      "refresh_token",
      "urn:ietf:params:oauth:grant-type:jwt-bearer"
   ],
   "response_types":["code id_token"],
   "application_type":"web",
   "id_token_signed_response_alg":"PS256",
   "id_token_encrypted_response_alg":"RSA-OAEP",
   "id_token_encrypted_response_enc:"A256GCM",
   "request_object_signing_alg":"PS256",
   "software_statement":"…",
   "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
   "org_name": "Mock Company Inc.",
   "client_name": "Mock Software",
   "client_description": "A mock software product for testing SSA",
   "client_uri": "https://www.mockcompany.com.au",
   "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
   "tos_uri": "https://www.mockcompany.com.au/tos.html",
   "policy_uri": "https://www.mockcompany.com.au/policy.html",
   "jwks_uri": "https://www.mockcompany.com.au/jwks",
   "revocation_uri": "https://www.mockcompany.com.au/revocation",
   "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
   "software_roles": "data-recipient-software-product",
   "scope":
         "openid
          bank:accounts.basic:read
          bank:accounts.detail:read
          bank:transactions:read
          bank:payees:read
          bank:regular_payments:read
          common:customer.basic:read
          common:customer.detail:read
          cdr:registration"
}

On successful registration, the response MUST be returned to the Accredited Data Recipient conforming to Section 3.2.1 of [RFC7591]

Claim Required Description
client_id Required Contains the dynamically generated identifier for the ADR Software Product issued by the Data Holder
client_id_issued_at Optional “Issued at time”

As per Section 3.2.1 of [RFC7591], additionally, the authorisation server MUST return all registered metadata about this client, including any fields provisioned by the authorisation server itself

The Software Statement value MUST be returned unmodified. Client metadata elements used from the software statement MUST also be returned directly as top-level client metadata values in the registration response

Any additional claims MUST be ignored and not returned on completion of the request

Registration Errors

Example Error Response

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
 "error": "invalid_software_statement",
 "error_description": "Duplicate registrations for a given software_id are not valid"
}

When an error condition occurs during a registration request, the response MUST be returned to the Accredited Data Recipient conforming to Section 3.2.2 of [RFC7591]

Duplicate registrations are not permitted so attempts to create a registration which already exists MUST return an HTTP 400 error

Registration error responses schemas are defined in the API Documentation

For those Registration errors which do not map to Section 3.2.2 of [RFC7591], HTTP Response Codes in the Consumer Data Standards should be used.

Client Registration Management

Registration API Endpoints

Data Holder Authorisation Servers must expose the following Client Registration Management endpoints

HTTP Verb Auth Server Support TLS-MA HoK Grant Type Access Token Scope
POST /register Required N/A None
GET /register/{clientID} Required Client Credentials cdr:registration
PUT /register/{clientID} Required Client Credentials cdr:registration
DELETE /register/{clientID} Optional Client Credentials cdr:registration

Please refer to API documentation for further examples

Authorisation Server

Non-Normative Example for access token retrieval

HTTP/1.1 POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
  scope=cdr%3Aregistration&
  client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
  client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...

## Decoded client assertion JWT
{
  "alg": "PS256",
  "typ": "JWT",
  "kid": "12456"
}
{
  "iss": "12345",
  "sub": "12345",
  "iat": 1516239022,
  "exp": 1516239322,
  "aud": "https://www.holder.com.au/token",
  "jti": "37747cd1-c105-4569-9f75-4adf28b73e31"
}

Token Endpoint Authentication

The Accredited Data Recipient MUST use the private_key_jwt client authentication method with the client_credentials grant to authenticate with the Data Holder token endpoint

Access Token Separation of Duties

Access tokens issued for consuming CDR Data should not be used for client registration maintenance and vice-versa

ADRs should ensure they only use access tokens with the scope cdr:registration for client registration maintenance tasks and CDR Authorisation Scopes for consuming CDR data

Registration Transaction Security

DCR API endpoints will conform to the same transaction security requirements as Data Holder Resource endpoints
Please refer to the Consumer Data Standards Transaction Security for Transaction Security details

Registration Flows

The following sequence diagrams outline the responsibilities for each party during the dynamic client registration processes.

Create Registration

Modify Registration

Software Product Configuration is a manual process performed via the CDR Participant Portal. Information on this process will be provided during onboarding Registration request details are described at: registration-request-using-jwt

Participant Statuses

Accredited Data Recipient and Software Product Statuses

The accreditation status of Accredited Data Recipients, and the status of their associated software products, may traverse through multiple statuses in the CDR as a result of decisions by the ACCC, in its capacity as Data Recipient Accreditor, or where an Accredited Data Recipient surrenders accreditation.

Data Holders will have the responsibility to ensure that CDR data relating to consumers is disclosed to Accredited Data Recipients and to cease sharing data where the accreditation of a data recipient is

  1. Suspended or revoked by the ACCC
  2. Surrendered by the Data Recipient

The Register will notify all Data Holders of the above changes in Accredited Data Recipient status as per the ACCC’s decisions.

Accredited Data Recipient Status

Software Product Status

Status Mapping

When the ACCC Registrar changes the accreditation status for an ADR for any status other than active, the associated Software Products status will be changed accordingly.

The cascading status mappings are as follows:

ADR Status Cascaded SP Status
Suspended Inactive
Revoked Inactive
Surrendered Removed

Data Holder Responsibilities


The ACCC Registrar has the ability to change the status of a Software Product independently of the ADR accreditation status. Therefore, both the ADR and Software Product statuses should be referenced, to determine the Data Holder's responsibilities for data disclosure, consent and registration management '

ADR Status SP Status Disclose of CDR Data Facilitate Consent Authorisation Facilitate Consent Withdrawal Consents Expire Cleanup Registration
Active Active
Active Inactive
Active Removed
Suspended Inactive
Suspended Removed
Revoked Inactive
Revoked Removed
Surrendered Removed

Metadata Cache Management

Data Holders are required to be able to react to Data Recipient and associated Software Statuses changes within 5 minutes of the change occuring on the CDR Register

To achieve this, Data Holders can poll the GetDataRecipientsStatus, GetSoftwareProductsStatus and GetDataRecipients APIs to retrieve the current statuses and cache these for use during requests for Consumer Data

Data Holders will need to choose a frequency of polling which ensures their systems can respond to status changes within the required timeframe

Data Holders and Data Recipients will be required to cache all other participant data they use and periodically update this cache using a slow poll. This ensures that changes to participant configuration propagates throughout the ecosystem in a predictable timeframe

Cache update periods

Cache update period - ADR and Software Product Statuses 2-5 minutes
Cache update period - Other Data 6 hours

Checking Request Validity

Request for Disclosure of CDR Data: Checking Validity of Accredited Data Recipient and associated Software Product

Pre-requisites: SSL connection has been established between all parties and Data Recipient has been issued an access token

Pre-requisites: SSL connection has been established between all parties

Status Changes

ADR Active

Once a Data Recipient has been granted accreditation by the ACCC (as Data Recipient Accreditor) and has completed the necessary steps to be added to the Register (as specified in the rules), the following actions and responsibilities will arise:

  1. The Registrar will issue the Accredited Data Recipient all required certificates
  2. The Accredited Data Recipient's status will be set to 'active'
  3. The Accredited Data Recipient will be able to register their Software Products with Data Holders within the ecosystem
  4. The Data Holder's responsibilities with this active Data Recipient are outlined at Data Holder Responsibilities

ADR Suspended

Where the ACCC (as Data Recipient Accreditor) has made a decision to suspend the accreditation of an Accredited Data Recipient, and has notified the decision to the Registrar the following actions and responsibilities will arise:

  1. The Registrar will update the CDR Register to change the Accredited Data Recipient's status to 'suspended' and status of all associated Software Products to 'inactive'
  2. The Data Holder will identify the change in status of the Data Recipient and associated Software Products during its next poll within the required timeframe
  3. The Data Holder's responsibilities with this suspended Data Recipient are outlined at Data Holder Responsibilities

ADR Reactivated from Suspension

An Accredited Data Recipient can move from the suspended status back to the active status when a suspension expires or is revoked by the ACCC (as Data Recipient Accreditor). Once this has occurred, the following actions and responsibilities are:

  1. The Registrar will update the CDR Register to change the Data Recipient's status to 'active'
  2. The Data Holder will identify the change in status of the Data Recipient during its next poll within the required timeframe
  3. The Data Holder's responsibilities with this reactivated Data Recipient are outlined at Data Holder Responsibilities
  4. Software Products for the associated Data Recipient will only be reactivated on a case by case basis

ADR Revoked

Where the ACCC (as Data Recipient Accreditor) has made a decision to revoke the accreditation of an Accredited Data Recipient, and has notified the decision to the Registrar, the following actions and responsibilities will arise:

  1. The Registrar will revoke Accredited Data Recipient's certificates
  2. The Registrar will update the CDR Register to change the Accredited Data Recipient's status to 'revoked' and status of all associated Software Products to 'inactive'
  3. Once the appeals timeframe has been exceeded, Software Products will be moved to the 'removed' status
  4. The Data Holder will identify the change in status of the Data Recipient and associated Software Products during its next poll within the required timeframe
  5. The Data Holder's responsibilities with this revoked Data Recipient are outlined at Data Holder Responsibilities

ADR Reactivated from Revoked

An Accredited Data Recipient can move from the revoked status back to the active status. Once this has occurred, the following actions and responsibilities are:

  1. The Registrar will reissue the Accredited Data Recipient all required certificates
  2. The Registrar will update the CDR Register to change the Data Recipient's status to 'active'
  3. The Data Holder will identify the change in status of the Data Recipient during its next poll within the required timeframe
  4. The Data Holder's responsibilities with this reactivated Data Recipient are outlined at Data Holder Responsibilities

ADR Surrendered

Where an Accredited Data Recipient has surrendered their accreditation, and the Data Recipient Accreditor has notified the Registrar of the surrender, the following actions and responsibilities will arise:

  1. The Registrar will revoke Accredited Data Recipient's certificates
  2. The Registrar will update the CDR Register to change the Accredited Data Recipient's status to 'surrendered' and status of all associated Software Products to 'removed'
  3. The Data Holder will identify the change in status of the Data Recipient and associated Software Products during its next poll within the required timeframe
  4. The Data Holder's responsibilities with this surrendered Data Recipient and associated Software Products are outlined at Data Holder Responsibilities

New ADR Software Product Active

Once an Accredited Data Recipient has completed the necessary steps to add a new Software Product to the Register, the following actions and responsibilities will arise:

  1. The Software Product status will be set to 'active'
  2. The Accredited Data Recipient will be able to register this Software Product with Data Holders within the ecosystem
  3. The Data Holder's responsibilities with this active ADR Software Product are outlined at Data Holder Responsibilities

ADR Software Product Deactivated

Where the ACCC (as Data Recipient Accreditor) has made a decision to deactivate the status of an Accredited Data Recipient’s Software Product, and has notified the decision to the Registrar the following actions and responsibilities will arise:

  1. The Registrar will update the CDR Register to change the Software Product’s status to 'inactive'
  2. The Data Holder will identify the change in status of the Software Product during its next poll within the required timeframe
  3. The Data Holder's responsibilities with this deactivated ADR Software Product are outlined at Data Holder Responsibilities

ADR Software Product Reactivated

A Software Product can move from the inactive status back to the active status where a suspension expires or is revoked by the ACCC (as Data Recipient Accreditor). Once this has occurred, the following actions and responsibilities are:

  1. The Registrar will update the CDR Register to change the Software Product’s status to 'active'
  2. The Data Holder will identify the change in status of the Software Product during its next poll within the required timeframe
  3. The Data Holder's responsibilities with this reactivated ADR Software Product are outlined at Data Holder Responsibilities

ADR Software Product Removed

Where the ACCC (as Data Recipient Accreditor) has made a decision to revoke the status of an Accredited Data Recipient’s Software Product, and has notified the decision to the Registrar, the following actions and responsibilities will arise:

  1. The Registrar will update the CDR Register to change the Software Product’s status to 'removed'
  2. The Data Holder will identify the change in status of the Software Product during its next poll within the required timeframe
  3. The Data Holder's responsibilities with this removed ADR Software Product are outlined at Data Holder Responsibilities

Data Holder Status Change

Rules regarding Data Holder off-boarding and revocation have not yet been provided. Updates to this design will be added once the rules have been defined.

Cache Refresh Metadata Request

To facilitate the Metadata update requests, Data Holders will need to implement the Admin endpoint as per CDS standard: https://consumerdatastandardsaustralia.github.io/standards/#admin-apis

This endpoint exposes functionality for the ACCC to request participants to refresh their caches. Cache refreshes may be requested in the following scenarios:

  1. A new Data Holder Brand becomes active
  2. A new Accredited Data Recipient Software Product becomes active
  3. A Data Holder Brand has been removed from the CDR
  4. An Accredited Data Recipient Software Product has been deactivated or removed from the CDR Register
  5. An Accredited Data Recipient has been surrendered, suspended or revoked from the CDR

Data Holder Caching of Accredited Data Recipients Software Product Metadata

Dataholdermetadatarefresh

Incident Management

Currently under the draft CDR rules, Data Holders within the CDR ecosystem will be able to refuse to disclose CDR data in response to valid requests from Accredited Data Recipients:

(a) where the Data Holder has reasonable grounds to believe that disclosure would create a real risk of harm or abuse to an individual or adversely impact the security, integrity or stability of the Register or the IT systems of the Data Holder used to receive and response to CDR data requests. Reliance on this exemption is to be notified to the ACCC within 24 hours; or

(b) in the circumstances set out in the standards

Security Profile

Overview

The security profile of the CDR Register follows the conventions defined by the Consumer Data Standards Security Profile

  1. The CDR Register Secured APIs will use Mutual Authentication TLS [MTLS] as the transport security and the OIDC
    client_credentials grant type authentication

  2. The CDR Register unsecured APIs will use [TLS] as the transport security with no authentication requirements

  3. All client and server certificates are generated by the CDR Register certificate authority to facilitate this transport. Please see the Certificate Management section for further details

  4. The Client Authentication method to be used by ADRs to the CDR Register will use private_key_jwt for procuring access tokens

Please refer to the Consumer Data Standards Security Overview for Symbols and Abbreviated Terms

Register Endpoints

The CDR Register exposes an OIDC Configuration Endpoint with associated JWKS and token endpoints to faciliate issuance of access tokens to consume the protected Register APIs.

Retrieve CDR Register OIDC Discovery Endpoint

GET /.well-known/openid-configuration HTTP/1.1
Host: cdr.register

## Response
{
    "issuer": "https://cdr.register/idp",
    "jwks_uri": "https://cdr.register/idp/.well-known/openid-configuration/jwks",
    "token_endpoint": "https://cdr.register/idp/connect/token",
    "claims_supported": ["sub"],
    "id_token_signing_alg_values_supported": ["PS256"],
    "subject_types_supported": ["public"],
    "scopes_supported": ["cdr-register:bank:read"],
    "response_types_supported": ["token"],
    "grant_types_supported": ["client_credentials"],
    "token_endpoint_auth_methods_supported": ["private_key_jwt"],
    "mutual_tls_sender_constrained_access_tokens": true,
    "request_object_signing_alg_values_supported": ["PS256"]
}

Request CDR Register Access Token

POST /token HTTP/1.1
Host: cdr.register
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
  client_id=12345&
  client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
  client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...&
  scope=cdr-register%3Abank%3Aread

## Decoded client assertion JWT
{
  "alg": "PS256",
  "typ": "JWT",
  "kid": "b50641343f8f4717a4865d238b6297b8"
}
{
  "iss": "12345",
  "sub": "12345",
  "exp": 1516239322,
  "aud": "https://cdr.register/idp/connect/token",
  "jti": "37747cd1-c105-4569-9f75-4adf28b73e31"
}


## Response
{
    "access_token": "eyJhbGciOiJQUz...",
    "expires_in": 7200,
    "token_type": "Bearer",
    "scope": "cdr-register:bank:read openid"
}

Retrieving Access Token

Client Authentication

Please refer to the Consumer Data Standard for reference to the client authentication methods between participants

Client Authentication with the CDR Register

Using the same client authentication approach as the Consumer Data Standards, interactions with the CDR Register use private_key_jwt Client Authentication method as specified at section 9 of [OIDC].

CDR Register Access Token Request using Client Authentication

As per the Consumer Data Standards, While [MTLS] is utilised for transaction security and as a Holder of Key mechanism the PKI Mutual TLS OAuth Client Authentication Method SHALL NOT be supported as the mechanism for client authentication.

  1. Access Token will be requested as per the Assertion Framework for OAuth2 Client Authentication profile
  2. Data Holder and Data Recipient public keys are retrieved from the CDR Register
  3. Refresh tokens will not be provided for grant_type client_credentials
  4. The JWT must contain the following Claim Values :

When invoking the protected end point, the assertion MUST be sent with the POST method and MUST include the following parameters:

Identifiers

client_id, sub and where appropriate iss, are expected to contain the unique identifier for the client.
The following client identifiers will be used:

Client Scenario Identifier
Data Recipient Brand Calls to Data Holder Brand Authenticated APIs Client ID as issued by the target Data Holder Brand
Data Recipient Brand Calls to CDR Register Authenticated APIs Data Recipient Brand ID as issued by CDR Register
Data Holder Brand Calls to Data Recipient Revocation API Data Holder Brand ID as issued by CDR Register
Data Holder Brand Calls to CDR Register Authenticated APIs Data Holder Brand ID as issued by CDR Register
CDR Register Calls to Data Holder Brand Admin APIs value: cdr-register

Transaction Security

Please refer to the Consumer Data Standards Transaction Security for Transaction Security details

Participant Endpoints

OIDC Discovery Configuration Endpoint

https://<InfoSecBaseUri>/.well-known/openid-configuration

Participants will be required to register base URIs to group the implementation of the Consumer Data Standards

Base URI DH ADR Description
PublicBaseUri Base URI for the Consumer Data Standard public endpoints. This should encompass all endpoints not requiring authentication
ResourceBaseUri Base URI for the Consumer Data Standard resource endpoints. This should encompass all CDS resource endpoints requiring authentication
InfoSecBaseUri Base URI for the Consumer Data Standard InfoSec endpoints. This should encompass all authentication and authorisation related endpoints
AdminBaseUri Base URI for the Consumer Data Standard admin endpoints called by the CDR Register
ExtensionBaseUri Base URI for the Data Holder extension endpoints to the Consumer Data Standard (optional)

Certificate Management

Issued by ACCC CA for Data Holders

Certificate Function Notes
Client Certificate Secures the following:
- Notifying ADRs of consent withdrawal
Server Certificate(s) Certificate is issued to a FQDN

Secures the following:
- Resource endpoint
- InfoSec endpoints
- Admin endpoints
It will be up to the DH on how these endpoints are
segregated. They may all be on the one domain
(so only one certificate required) or could be separated

Issued by ACCC CA for Accredited Data Recipients

Certificate Function Notes
Client Certificate Secures the following:
- Consuming Register APIs
- Consuming Data Holder APIs
Server Certificate(s) Certificate is issued to a FQDN

Secures the following:
- InfoSec endpoints
ADRs will be required to secure their Revocation Endpoint with an
ACCC CA issued certificate

CDR Certificate Authority

DigiCert will act as the certificate authority that issues and manages certificates to CDR participants as directed by the ACCC in its capacity as the CDR Registrar.

Availability

The following scenarios outline the expectations of Data Holders and Accredited Data Recipients within the Consumer Data Right ecosystem when outages occur

CDR Register Unavailable

Result Data Holders will not be able to communicate with the CDR Register
Impact Data Holders will not be able to maintain up-to-date status information of Data Recipients and Software Products
Impact Data Holders will not be able to detect when new Data Recipients and/or associated Software Products enter the ecosystem
Expectation It is not expected that the status of an ADR or Software Product will change when the CDR Register is unavailable. Data Holders will continue to operate until their metadata caches reach a maximum age.
Once this time has been reached, consumer data will not be shared.
Once the CDR Register becomes available, all Data Holders will retrieve up-to-data status information on their next poll
Expectation Data Holders must not facilitate the sharing of consumer data with Data Recipients of which they are uncertain of their accreditation and/or Software Product status
Result Data Recipients will not be able to communicate with the CDR Register
Impact Data Recipients will not be able to retrieve SSAs, therefore, won't be able to register with any Data Holders
Impact Data Recipients will not be able to detect when new Data Holders enter the ecosystem
Expectation Data Recipients will need to wait until the CDR Register becomes available to register with a Data Holder

Certificate Authority Unavailable

Result OCSP services will not be available
Impact Participants will not be able verify the status of CA certificates
Expectation Participants will honour cached Certificate statuses from previous OCSP checks.
Once cached certificate statuses have expired, data sharing will stop
It can be expected that CA certificate statuses will not change while the CA is unavailable
Once the CA becomes available, certificate statuses are again updated through OCSP

Accredited Data Recipient Unavailable

Result Data Holders will not be able to communicate with the Accredited Data Recipient
Impact Data Holders will not be able to inform the ADR that consent has been withdrawn
Expectation Data Holders will need to continually poll the ADR until recovery.
Upon recovery, the authorisation withdrawal process will need to be executed as required

Data Holder Unavailable

Result Accredited Data Recipients will not be able to communicate with Data Holders
Impact Accredited Data Recipients will not be able to inform the Data Holder of change in consent
Impact Accredited Data Recipients will not be able to retrieve Product & Consumer data
Expectation Accredited Data Recipients will need to continually poll the Data Holder until recovery
Upon recovery, the consent withdrawal process will need to be executed as required
Result The CDR Register will not be able to communicate with the Data Holder
Impact The CDR Register will not be able to retrieve metrics information
Expectation The CDR Register will back-fill metrics once the Data Holder becomes available

Versioning

ACCC will follow the versioning conventions outlined by the Data Standards Body.
Refer https://consumerdatastandardsaustralia.github.io/standards/#versioning

It is expected that management of standards for the Register will be incorporated into the remit of the Data Standards Body once mature. The initial version of the Register APIs will align with versions published for the Consumer Data Standards.

A deprecation strategy will be developed in consultation with the Data Standards Body and industry.

The following table illustrates concurrent versioning requirements to ensure backward compatibility. Q indicates a nominal three-month period. When changes are made they are notified at the commencement of a quarter.

Q1 Q2 Q3 Q4 Q5 Q6
Get Data Holders V1.0.0 V1.0.0
V1.1.0
V1.0.0
V1.1.0
V1.1.0
V1.2.0
V1.1.0
V1.2.0
V1.2.0
Get Data Recipients V1.0.0 V1.0.0 V1.0.0
V1.1.0
V1.0.0
V1.1.0
V1.1.0
V1.2.0
V1.1.0
V1.2.0

Register APIs

API Caller Description mTLS TLS Bearer Token
GetDataHolderBrands Data Recipient Discovery of DH Brands and their associated endpoints
GetSoftwareStatementAssertion Data Recipient Get SSA for a Software Product to be used in Dynamic Client Registration
GetSoftwareProductsStatus Data Holder Software Product Statuses to check validity of ADR requests
GetDataRecipientsStatus Data Holder Data Recipient Statuses to check validity of ADR requests
GetDataRecipients Data Holder Data Recipient, brand and product details to render Data Holder Consumer Dashboard

Base URLs:

GetDataHolderBrands

Get Data Holder Brands from the CDR Register

Code samples

GET https://<register-base-url>/cdr-register/v1/{industry}/data-holders/brands HTTP/1.1
Host: <register-base-url>
Accept: application/json
Authorization: Bearer <access-token>
x-v: string

GET /{industry}/data-holders/brands

Parameters

Name In Type Required Description
industry path string true The industry the participant is retrieving data for (Banking, etc)
updated-since query string(date-time) false none
page query integer(int32) false none
page-size query integer(int32) false none
Authorization header string true An Authorisation Token as per RFC6750
x-v header string false none

Enumerated Values

Parameter Value
industry banking

Example responses

200 Response

{
  "data": [
    {
      "dataHolderBrandId": "string",
      "brandName": "string",
      "industry": "banking",
      "legalEntity": {
        "legalEntityId": "string",
        "legalEntityName": "string",
        "registrationNumber": "string",
        "registrationDate": "2019-10-24",
        "registeredCountry": "string",
        "abn": "string",
        "acn": "string",
        "arbn": "string",
        "industryCode": "string",
        "organisationType": "SOLE_TRADER"
      },
      "status": "ACTIVE",
      "endpointDetail": {
        "version": "string",
        "publicBaseUri": "string",
        "resourceBaseUri": "string",
        "infosecBaseUri": "string",
        "extensionBaseUri": "string",
        "websiteUri": "string"
      },
      "authDetails": [
        {
          "registerUType": "HYBRIDFLOW-JWKS",
          "jwksEndpoint": "string"
        }
      ],
      "lastUpdated": "2019-10-24T03:51:44Z"
    }
  ],
  "links": {
    "first": "string",
    "last": "string",
    "next": "string",
    "prev": "string",
    "self": "string"
  },
  "meta": {
    "totalPages": 0,
    "totalRecords": 0
  }
}

Responses

Status Meaning Description Schema
200 OK Success ResponseRegisterDataHolderBrandList
400 Bad Request Bad Request ResponseErrorList
403 Forbidden Forbidden ResponseErrorList

GetSoftwareStatementAssertion (SSA)

Get a Software Statement Assertion (SSA) for a software product on the CDR Register to be used for Dynamic Registration with a Data Holder

Code samples

GET https://<register-base-url>/cdr-register/v1/{industry}/data-recipients/brands/{dataRecipientBrandId}/software-products/{softwareProductId}/ssa HTTP/1.1
Host: <register-base-url>
Accept: application/json
Authorization: Bearer <access-token>
x-v: string

GET /{industry}/data-recipients/brands/{dataRecipientBrandId}/software-products/{softwareProductId}/ssa

Parameters

Name In Type Required Description
industry path string true The industry the participant is retrieving data for (Banking, etc)
dataRecipientBrandId path string true Unique id for the Accredited Data Recipient Brand that the Software Product is associated with in the CDR Register
softwareProductId path string true Unique id for the Accredited Data Recipient Software Product in the CDR Register
Authorization header string true An Authorisation Token as per RFC6750
x-v header string false none

Enumerated Values

Parameter Value
industry banking

Example responses

200 Response

"string"

Responses

Status Meaning Description Schema
200 OK Success string
400 Bad Request Bad Request ResponseErrorList
403 Forbidden Forbidden ResponseErrorList
404 Not Found Not Found ResponseErrorList

GetSoftwareProductsStatus

Get the statuses for software products from the CDR Register

Code samples

GET https://<register-base-url>/cdr-register/v1/{industry}/data-recipients/brands/software-products/status HTTP/1.1
Host: <register-base-url>
Accept: application/json
x-v: string

GET /{industry}/data-recipients/brands/software-products/status

Parameters

Name In Type Required Description
industry path string true The industry the participant is retrieving data for (Banking, etc)
x-v header string false none

Enumerated Values

Parameter Value
industry banking

Example responses

200 Response

{
  "softwareProducts": [
    {
      "softwareProductId": "string",
      "softwareProductStatus": "ACTIVE"
    }
  ]
}

Responses

Status Meaning Description Schema
200 OK Success SoftwareProductsStatusList
400 Bad Request Bad Request ResponseErrorList

GetDataRecipientsStatus

Get the statuses for Data Recipients from the CDR Register

Code samples

GET https://<register-base-url>/cdr-register/v1/{industry}/data-recipients/status HTTP/1.1
Host: <register-base-url>
Accept: application/json
x-v: string

GET /{industry}/data-recipients/status

Parameters

Name In Type Required Description
industry path string true The industry the participant is retrieving data for (Banking, etc)
x-v header string false none

Enumerated Values

Parameter Value
industry banking

Example responses

200 Response

{
  "dataRecipients": [
    {
      "dataRecipientId": "string",
      "dataRecipientStatus": "ACTIVE"
    }
  ]
}

Responses

Status Meaning Description Schema
200 OK Success DataRecipientsStatusList
400 Bad Request Bad Request ResponseErrorList

GetDataRecipients

Code samples

GET https://<register-base-url>/cdr-register/v1/{industry}/data-recipients HTTP/1.1
Host: <register-base-url>
Accept: application/json
x-v: string

GET /{industry}/data-recipients

Parameters

Name In Type Required Description
industry path string true The industry the participant is retrieving data for (Banking, etc)
x-v header string false none

Enumerated Values

Parameter Value
industry banking

Example responses

200 Response

{
  "data": [
    {
      "legalEntityId": "string",
      "legalEntityName": "string",
      "industry": "banking",
      "logoUri": "string",
      "dataRecipientBrands": [
        {
          "dataRecipientBrandId": "string",
          "brandName": "string",
          "logoUri": "string",
          "softwareProducts": [
            {
              "softwareProductId": "string",
              "softwareProductName": "string",
              "softwareProductDescription": "string",
              "logoUri": "string",
              "status": "ACTIVE"
            }
          ],
          "status": "ACTIVE"
        }
      ],
      "status": "ACTIVE",
      "lastUpdated": "2019-10-24T03:51:44Z"
    }
  ]
}

Responses

Status Meaning Description Schema
200 OK Success ResponseRegisterDataRecipientList
400 Bad Request Bad Request ResponseErrorList
403 Forbidden Forbidden ResponseErrorList

Schemas

ResponseRegisterDataHolderBrandList

{
  "data": [
    {
      "dataHolderBrandId": "string",
      "brandName": "string",
      "industry": "banking",
      "legalEntity": {
        "legalEntityId": "string",
        "legalEntityName": "string",
        "registrationNumber": "string",
        "registrationDate": "2019-10-24",
        "registeredCountry": "string",
        "abn": "string",
        "acn": "string",
        "arbn": "string",
        "industryCode": "string",
        "organisationType": "SOLE_TRADER"
      },
      "status": "ACTIVE",
      "endpointDetail": {
        "version": "string",
        "publicBaseUri": "string",
        "resourceBaseUri": "string",
        "infosecBaseUri": "string",
        "extensionBaseUri": "string",
        "websiteUri": "string"
      },
      "authDetails": [
        {
          "registerUType": "HYBRIDFLOW-JWKS",
          "jwksEndpoint": "string"
        }
      ],
      "lastUpdated": "2019-10-24T03:51:44Z"
    }
  ],
  "links": {
    "first": "string",
    "last": "string",
    "next": "string",
    "prev": "string",
    "self": "string"
  },
  "meta": {
    "totalPages": 0,
    "totalRecords": 0
  }
}

Response containing a list of Register Data Holder Brand objects

Properties

Name Type Required Restrictions Description
data [RegisterDataHolderBrand] true none Response data for the query
links LinksPaginated true none none
meta MetaPaginated true none none

RegisterDataHolderBrand

{
  "dataHolderBrandId": "string",
  "brandName": "string",
  "industry": "banking",
  "legalEntity": {
    "legalEntityId": "string",
    "legalEntityName": "string",
    "registrationNumber": "string",
    "registrationDate": "2019-10-24",
    "registeredCountry": "string",
    "abn": "string",
    "acn": "string",
    "arbn": "string",
    "industryCode": "string",
    "organisationType": "SOLE_TRADER"
  },
  "status": "ACTIVE",
  "endpointDetail": {
    "version": "string",
    "publicBaseUri": "string",
    "resourceBaseUri": "string",
    "infosecBaseUri": "string",
    "extensionBaseUri": "string",
    "websiteUri": "string"
  },
  "authDetails": [
    {
      "registerUType": "HYBRIDFLOW-JWKS",
      "jwksEndpoint": "string"
    }
  ],
  "lastUpdated": "2019-10-24T03:51:44Z"
}

Properties

Name Type Required Restrictions Description
dataHolderBrandId string true none none
brandName string true none none
industry string true none none
legalEntity LegalEntityDetail true none The data that is common to all organisations, regardless of the type (e.g. company, trust, partnership, government)
status string true none none
endpointDetail RegisterDataHolderBrandServiceEndpoint true none Endpoints related to Data Holder Brand services
authDetails [RegisterDataHolderAuth] true none [Provides details of authorisation endpoints for Data Holders]
lastUpdated string(date-time) true none The date/time that the Data Holder Brand data was last updated in the Register

Enumerated Values

Property Value
industry banking
status ACTIVE
status INACTIVE
status REMOVED

SoftwareProductsStatusList

{
  "softwareProducts": [
    {
      "softwareProductId": "string",
      "softwareProductStatus": "ACTIVE"
    }
  ]
}

Properties

Name Type Required Restrictions Description
softwareProducts [SoftwareProductStatus] true none none

SoftwareProductStatus

{
  "softwareProductId": "string",
  "softwareProductStatus": "ACTIVE"
}

Properties

Name Type Required Restrictions Description
softwareProductId string true none Unique id of the software product issued by the CDR Register
softwareProductStatus string true none Software product status in the CDR Register

Enumerated Values

Property Value
softwareProductStatus ACTIVE
softwareProductStatus INACTIVE
softwareProductStatus REMOVED

DataRecipientsStatusList

{
  "dataRecipients": [
    {
      "dataRecipientId": "string",
      "dataRecipientStatus": "ACTIVE"
    }
  ]
}

Properties

Name Type Required Restrictions Description
dataRecipients [DataRecipientStatus] true none none

DataRecipientStatus

{
  "dataRecipientId": "string",
  "dataRecipientStatus": "ACTIVE"
}

Properties

Name Type Required Restrictions Description
dataRecipientId string true none Unique id of the Data Recipient in the CDR Register
dataRecipientStatus string true none Data Recipient status in the CDR Register

Enumerated Values

Property Value
dataRecipientStatus ACTIVE
dataRecipientStatus SUSPENDED
dataRecipientStatus REVOKED
dataRecipientStatus SURRENDERED

ResponseRegisterDataRecipientList

{
  "data": [
    {
      "legalEntityId": "string",
      "legalEntityName": "string",
      "industry": "banking",
      "logoUri": "string",
      "dataRecipientBrands": [
        {
          "dataRecipientBrandId": "string",
          "brandName": "string",
          "logoUri": "string",
          "softwareProducts": [
            {
              "softwareProductId": "string",
              "softwareProductName": "string",
              "softwareProductDescription": "string",
              "logoUri": "string",
              "status": "ACTIVE"
            }
          ],
          "status": "ACTIVE"
        }
      ],
      "status": "ACTIVE",
      "lastUpdated": "2019-10-24T03:51:44Z"
    }
  ]
}

Response containing a list of Data Recipients in the CDR Register

Properties

Name Type Required Restrictions Description
data [RegisterDataRecipient] true none Response data for the query

RegisterDataRecipient

{
  "legalEntityId": "string",
  "legalEntityName": "string",
  "industry": "banking",
  "logoUri": "string",
  "dataRecipientBrands": [
    {
      "dataRecipientBrandId": "string",
      "brandName": "string",
      "logoUri": "string",
      "softwareProducts": [
        {
          "softwareProductId": "string",
          "softwareProductName": "string",
          "softwareProductDescription": "string",
          "logoUri": "string",
          "status": "ACTIVE"
        }
      ],
      "status": "ACTIVE"
    }
  ],
  "status": "ACTIVE",
  "lastUpdated": "2019-10-24T03:51:44Z"
}

Properties

Name Type Required Restrictions Description
legalEntityId string true none Unique id of the Data Recipient Legal Entity
legalEntityName string true none Legal name of the Data Recipient
industry string true none none
logoUri string true none Legal Entity logo URI
dataRecipientBrands [DataRecipientBrandMetaData] false none [Endpoints related to Data Holder Brand services]
status string true none none
lastUpdated string(date-time) true none The date/time that the Legal Entity was last updated in the Register

Enumerated Values

Property Value
industry banking
status ACTIVE
status SUSPENDED
status REVOKED
status SURRENDERED

DataRecipientBrandMetaData

{
  "dataRecipientBrandId": "string",
  "brandName": "string",
  "logoUri": "string",
  "softwareProducts": [
    {
      "softwareProductId": "string",
      "softwareProductName": "string",
      "softwareProductDescription": "string",
      "logoUri": "string",
      "status": "ACTIVE"
    }
  ],
  "status": "ACTIVE"
}

Endpoints related to Data Holder Brand services

Properties

Name Type Required Restrictions Description
dataRecipientBrandId string true none Unique id of the Data Recipient brand
brandName string true none Data Recipient Brand name
logoUri string true none Data Recipient Brand logo URI
softwareProducts [SoftwareProductMetaData] false none [Data Recipient Brand Software Products]
status string true none none

Enumerated Values

Property Value
status ACTIVE
status INACTIVE
status REMOVED

SoftwareProductMetaData

{
  "softwareProductId": "string",
  "softwareProductName": "string",
  "softwareProductDescription": "string",
  "logoUri": "string",
  "status": "ACTIVE"
}

Data Recipient Brand Software Products

Properties

Name Type Required Restrictions Description
softwareProductId string true none Unique id of the Data Recipient software product
softwareProductName string true none Name of the software product
softwareProductDescription string false none Description of the software product
logoUri string true none Software product logo URI
status string true none none

Enumerated Values

Property Value
status ACTIVE
status INACTIVE
status REMOVED

LegalEntityDetail

{
  "legalEntityId": "string",
  "legalEntityName": "string",
  "registrationNumber": "string",
  "registrationDate": "2019-10-24",
  "registeredCountry": "string",
  "abn": "string",
  "acn": "string",
  "arbn": "string",
  "industryCode": "string",
  "organisationType": "SOLE_TRADER"
}

The data that is common to all organisations, regardless of the type (e.g. company, trust, partnership, government)

Properties

Name Type Required Restrictions Description
legalEntityId string true none Unique legal name of the organisation
legalEntityName string true none Unique legal name of the organisation
registrationNumber string false none Unique registration number (if the company is registered outside Australia)
registrationDate string(date) false none Date of registration (if the company is registered outside Australia)
registeredCountry string true none Country of registeration (if the company is registered outside Australia)
abn string false none Australian Business Number for the organisation
acn string false none Australian Company Number for the organisation
arbn string false none Australian Registered Body Number. ARBNs are issued to registrable Australian bodies and foreign companies
industryCode string false none Industry Code for the organisation. ANZSIC (2006)
organisationType string false none Legal organisation type

Enumerated Values

Property Value
organisationType SOLE_TRADER
organisationType COMPANY
organisationType PARTNERSHIP
organisationType TRUST
organisationType GOVERNMENT_ENTITY
organisationType OTHER

RegisterDataHolderBrandServiceEndpoint

{
  "version": "string",
  "publicBaseUri": "string",
  "resourceBaseUri": "string",
  "infosecBaseUri": "string",
  "extensionBaseUri": "string",
  "websiteUri": "string"
}

Endpoints related to Data Holder Brand services

Properties

Name Type Required Restrictions Description
version string true none The major version of the high level standards. This is not the version of the endpoint or the payload being requested but the version of the overall standards being applied. This version number will be "v" followed by the major version of the standards as a positive integer (e.g. v1, v12 or v76)
publicBaseUri string true none Base URI for the Data Holder's Consumer Data Standard public endpoints
resourceBaseUri string true none Base URI for the Data Holder's Consumer Data Standard resource endpoints
infosecBaseUri string true none Base URI for the Data Holder's Consumer Data Standard information security endpoints
extensionBaseUri string false none Base URI for the Data Holder extension endpoints to the Consumer Data Standard (optional)
websiteUri string true none Publicly available website or web resource URI

RegisterDataHolderAuth

{
  "registerUType": "HYBRIDFLOW-JWKS",
  "jwksEndpoint": "string"
}

Provides details of authorisation endpoints for Data Holders

Properties

Name Type Required Restrictions Description
registerUType string true none The type of authentication and authorisation in use
jwksEndpoint string true none JWKS endpoint for private_key_jwt client auth with Data Recipient

Enumerated Values

Property Value
registerUType HYBRIDFLOW-JWKS

LinksPaginated

{
  "first": "string",
  "last": "string",
  "next": "string",
  "prev": "string",
  "self": "string"
}

Properties

Name Type Required Restrictions Description
first string false none URI to the first page of this set. Mandatory if this response is not the first page
last string false none URI to the last page of this set. Mandatory if this response is not the last page
next string false none URI to the next page of this set. Mandatory if this response is not the last page
prev string false none URI to the previous page of this set. Mandatory if this response is not the first page
self string true none Fully qualified link to this API call

MetaPaginated

{
  "totalPages": 0,
  "totalRecords": 0
}

Properties

Name Type Required Restrictions Description
totalPages integer(int32) true none The total number of pages in the full set
totalRecords integer(int32) true none The total number of records in the full set

ResponseErrorList

{
  "errors": [
    {
      "code": "string",
      "title": "string",
      "detail": "string",
      "meta": {}
    }
  ]
}

Properties

Name Type Required Restrictions Description
errors [Error] true none none

Error

{
  "code": "string",
  "title": "string",
  "detail": "string",
  "meta": {}
}

Properties

Name Type Required Restrictions Description
code string true none Error code
title string true none Error title
detail string true none Error detail
meta object false none Optional additional data for specific error types

DCR API

This specification defines the APIs for Data Holders exposing Dynamic Client Registration endpoints


DCR Swagger (JSON)
DCR Swagger (YAML)

Register a client using a CDR Register issued Software Statement Assertion

Code samples

HTTP/1.1 POST /register 
Content-Type: application/jwt
Accept: application/json
x-v: string

POST /register

Body parameter

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Parameters

Name In Type Required Description
registrationRequest body string(jwt) true The registration request JWT, as defined in Dynamic Client Registration, to be used to register with a Data Holder

Example responses

201 Response

HTTP/1.1 201 Created
Content-Type: application/json
{
  "client_id": "35a5a70b-5b8d-41f4-9cbd-96cfbc15c58a",
  "client_id_issued_at": 1571808167,
  "client_name": "Mock Software",
  "client_description": "A mock software product",
  "client_uri": "https://www.mockcompany.com.au",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "token_endpoint_auth_method": "private_key_jwt",
  "token_endpoint_auth_signing_alg": "PS256",
  "grant_types": [
    "client_credentials"
  ],
  "response_types": [
    "code id_token"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "string",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "scope": "bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read"
}

400 Responses

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
 "error": "invalid_redirect_uri",
 "error_description": "One or more redirect_uri values are invalid"
}
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
 "error": "invalid_software_statement",
 "error_description": "Duplicate registrations for a given software_id are not invalid"
}

Responses

Status Meaning Description Schema
201 Created Client registration success RegistrationProperties
400 Bad Request Request failed due to client error RegistrationError

Get a Client Registration for a given Client ID

Code samples

GET /register/{ClientId} HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>

GET /register/{ClientId}

Parameters

Name In Type Required Description
ClientId path string true The client ID issued by the target Data Holder
Authorization header string true An Authorisation Token as per RFC6750

Example responses

200 Response

{
  "client_id": "35a5a70b-5b8d-41f4-9cbd-96cfbc15c58a",
  "client_id_issued_at": 1571808167,
  "client_name": "Mock Software",
  "client_description": "A mock software product",
  "client_uri": "https://www.mockcompany.com.au",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "token_endpoint_auth_method": "private_key_jwt",
  "token_endpoint_auth_signing_alg": "PS256",
  "grant_types": [
    "client_credentials"
  ],
  "response_types": [
    "code id_token"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "string",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "scope": "bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read"
}

401 Response

HTTP/1.1 401 Unauthorized
WWW-Authenticate:   Bearer error="invalid_token", 
                    error_description="The access token expired"

Responses

Status Meaning Description Schema
200 OK Client registration retrieval success RegistrationProperties
401 Unauthorized Request failed due to unknown or invalid Client or invalid access token None
403 Forbidden The client does not have permission to read, update or delete the Client None

Response Headers

Status Header Type Format Description
401 WWW-Authenticate string The Response Header Field as per RFC6750

Update a Client Registration for a given Client ID

Code samples

PUT /register/{ClientId} HTTP/1.1
Content-Type: application/jwt
Accept: application/json
Authorization: Bearer <access-token>

PUT /register/{ClientId}

Body parameter

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Parameters

Name In Type Required Description
ClientId path string true The client ID issued by the target Data Holder
Authorization header string true An Authorisation Token as per RFC6750
registrationRequest body string(jwt) true The registration request JWT, as defined in Dynamic Client Registration, to be used to register with a Data Holder.

Example responses

200 Response

{
  "client_id": "35a5a70b-5b8d-41f4-9cbd-96cfbc15c58a",
  "client_id_issued_at": 1571808167,
  "client_name": "Mock Software",
  "client_description": "A mock software product",
  "client_uri": "https://www.mockcompany.com.au",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "token_endpoint_auth_method": "private_key_jwt",
  "token_endpoint_auth_signing_alg": "PS256",
  "grant_types": [
    "client_credentials"
  ],
  "response_types": [
    "code id_token"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "string",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "scope": "bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read"
}

Responses

Status Meaning Description Schema
200 OK Client registration update success RegistrationProperties
400 Bad Request Request failed due to client error RegistrationError
401 Unauthorized Request failed due to unknown or invalid Client or invalid access token None
403 Forbidden The client does not have permission to read, update or delete the Client None

Response Headers

Status Header Type Format Description
401 WWW-Authenticate string The Response Header Field as per RFC6750

Delete a Client Registration for a given Client ID

Code samples

DELETE /register/{ClientId} HTTP/1.1
Authorization: Bearer <access-token>

DELETE /register/{ClientId}

Parameters

Name In Type Required Description
ClientId path string true The client ID issued by the target Data Holder
Authorization header string true An Authorisation Token as per RFC6750

Responses

Status Meaning Description Schema
204 No Content Client deleted None
401 Unauthorized Request failed due to unknown or invalid Client or invalid access token None
403 Forbidden The client does not have permission to read, update or delete the Client None
405 Method Not Allowed The client does not have permission to read, update or delete the Client None

Response Headers

Status Header Type Format Description
401 WWW-Authenticate string The Response Header Field as per RFC6750

Schemas

RegistrationProperties

{
  "client_id": "35a5a70b-5b8d-41f4-9cbd-96cfbc15c58a",
  "client_id_issued_at": 1571808167,
  "client_name": "Mock Software",
  "client_description": "A mock software product",
  "client_uri": "https://www.mockcompany.com.au",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "token_endpoint_auth_method": "private_key_jwt",
  "token_endpoint_auth_signing_alg": "PS256",
  "grant_types": [
    "client_credentials"
  ],
  "response_types": [
    "code id_token"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "string",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "scope": "bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read"
}

Properties

Name Type Required Restrictions Description
client_id string true none Data Holder issued client identifier string
client_id_issued_at integer(int32) false none Time at which the client identifier was issued expressed as seconds since 1970-01-01T00:00:00Z as measured in UTC
client_name string true none Human-readable string name of the software product to be presented to the end-user during authorization
client_description string true none Human-readable string name of the software product description to be presented to the end user during authorization
client_uri string true none URL string of a web page providing information about the client
org_id string true none A unique identifier string assigned by the CDR Register that identifies the Accredited Data Recipient Brand
org_name string true none Human-readable string name of the Accredited Data Recipient to be presented to the end user during authorization
redirect_uris [string] true none Array of redirection URI strings for use in redirect-based flows
logo_uri string true none URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval
tos_uri string false none URL string that points to a human-readable terms of service document for the Software Product
policy_uri string false none URL string that points to a human-readable policy document for the Software Product
jwks_uri string true none URL string referencing the client JSON Web Key (JWK) Set [RFC7517] document, which contains the client public keys
revocation_uri string true none URI string that references the location of the Software Product consent revocation endpoint
token_endpoint_auth_method string true none The requested authentication method for the token endpoint
token_endpoint_auth_signing_alg string true none The algorithm used for signing the JWT
grant_types [string] true none Array of OAuth 2.0 grant type strings that the client can use at the token endpoint
response_types [string] true none Array of the OAuth 2.0 response type strings that the client can use at the authorization endpoint.
application_type string false none Kind of the application. The only supported application type will be web
id_token_signed_response_alg string false none Algorithm with which an id_token is to be signed
id_token_encrypted_response_alg string true none JWE alg algorithm with which an id_token is to be encrypted
id_token_encrypted_response_enc string true none JWE enc algorithm with which an id_token is to be encrypted
request_object_signing_alg string false none Algorithm which the ADR expects to sign the request object if a request object will be part of the authorization request sent to the Data Holder
software_statement string(JWT) true none The Software Statement Assertion, as defined in Dynamic Client Registration
software_id string true none String representing a unique identifier assigned by the ACCC Register and used by registration endpoints to identify the software product to be dynamically registered.

The "software_id" will remain the same for the lifetime of the product, across multiple updates and versions
scope string true none String containing a space-separated list of scope values that the client can use when requesting access tokens.

Enumerated Values

Property Value
token_endpoint_auth_method private_key_jwt
token_endpoint_auth_signing_alg PS256
token_endpoint_auth_signing_alg ES256
application_type web
id_token_signed_response_alg PS256
id_token_signed_response_alg ES256
request_object_signing_alg PS256
request_object_signing_alg ES256

ClientRegistration

{
  "iss": "Mock Company",
  "iat": 1571808167,
  "exp": 2147483646,
  "jti": "37747cd1c10545699f754adf28b73e31",
  "aud": "https://secure.api.dataholder.com",
  "client_id": "35a5a70b-5b8d-41f4-9cbd-96cfbc15c58a",
  "client_id_issued_at": 1571808167,
  "client_name": "Mock Software",
  "client_description": "A mock software product",
  "client_uri": "https://www.mockcompany.com.au",
  "org_id": "3B0B0A7B-3E7B-4A2C-9497-E357A71D07C8",
  "org_name": "Mock Company Inc.",
  "redirect_uris": [
    "https://www.mockcompany.com.au/redirects/redirect1",
    "https://www.mockcompany.com.au/redirects/redirect2"
  ],
  "logo_uri": "https://www.mockcompany.com.au/logos/logo1.png",
  "tos_uri": "https://www.mockcompany.com.au/tos.html",
  "policy_uri": "https://www.mockcompany.com.au/policy.html",
  "jwks_uri": "https://www.mockcompany.com.au/jwks",
  "revocation_uri": "https://www.mockcompany.com.au/revocation",
  "token_endpoint_auth_method": "private_key_jwt",
  "token_endpoint_auth_signing_alg": "PS256",
  "grant_types": [
    "client_credentials"
  ],
  "response_types": [
    "code id_token"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "PS256",
  "id_token_encrypted_response_alg": "RSA-OAEP",
  "id_token_encrypted_response_enc": "A256GCM",
  "request_object_signing_alg": "PS256",
  "software_statement": "string",
  "software_id": "740C368F-ECF9-4D29-A2EA-0514A66B0CDE",
  "scope": "bank:accounts.basic:read bank:accounts.detail:read bank:transactions:read bank:payees:read bank:regular_payments:read common:customer.basic:read common:customer.detail:read"
}

Properties

allOf

Name Type Required Restrictions Description
anonymous object false none none
» iss string true none Unique identifier for the Data Holder issued by the CDR Register
» iat integer(int32) true none The time at which the request was issued by the TPP expressed as seconds since 1970-01-01T00:00:00Z as measured in UTC
» exp integer(int32) true none The time at which the request expires expressed as seconds since 1970-01-01T00:00:00Z as measured in UTC
» jti string true none Unique identifier for the JWT, used to prevent replay of the token
» aud string true none The audience for the request. This should be the Data Holder authorisation server URI

and

Name Type Required Restrictions Description
anonymous RegistrationProperties false none none

RegistrationError

{
  "error": "invalid_redirect_uri",
  "error_description": "string"
}

Properties

Name Type Required Restrictions Description
error string true none Predefined error code as described in section 3.3 OIDC Dynamic Client Registration
invalid_redirect_uri - The value of one or more redirection URIs is invalid.
invalid_client_metadata - The value of one of the client metadata fields is invalid and the server has rejected this request. This error value is also used when attempts at duplicate registrations for the same software_id are rejected
invalid_software_statement - The software statement presented is invalid.
unapproved_software_statement - The software statement presented is not approved for use by this authorization server.
error_description string false none Additional text description of the error for debugging.

Enumerated Values

Property Value
error invalid_redirect_uri
error invalid_client_metadata
error invalid_software_statement
error unapproved_software_statement

Change Log

Documentation versioning will follow the following conventions

x.y.z
x major version formal release and breaking changes
y minor version non-breaking design changes
z point version documentation improvements and clarification



The following table lists the changes made in reverse date order (most recent change is at the top)

Date Register API Ver Description Detail Of Change
03/02/2020 1.1.0 Maintenance updates See release notes for detail
10/12/2019 1.0.5 Updated Security Profile Added Register Endpoint section detailing Register access token retrieval
Updated overview to clarify security profile requirements
10/12/2019 1.0.5 Updated Client Registration Added modifiable column to the SSA definition to explicitly outline what can be changed
25/11/2019 1.0.4 Participant Statuses Updated status sequence diagrams to explicitly model the status checks required
Updated the associated status change descriptions to refer to the Data Holder Responsibilities matrix
25/11/2019 1.0.4 Register APIs Added use case descriptions to each API to explicitly outline their intent
25/11/2019 1.0.4 CDR Register Updated ecosystem so that CDR Register exposes InfoSec APIs to facilitate OIDC
Updated API requirements to include Data Recipient information discovery
25/11/2019 1.0.4 Security Profile Updated client authentication identifier references to include the DH to ADR revocation API and specify where the identifiers are issued from
Updated Client Certificates, corrected Accredited Data Recipients certificates to be used for consuming the Register and DH APIs
25/11/2019 1.0.4 Client Registration Updated references to the RFC7591 standards and added further detail to the provided examples
20/11/2019 1.0.3 Updated DCR Swagger Added descriptions to error codes to explicitly detail how duplicate registration requests are handled
20/11/2019 1.0.3 Client Registration Updated Registration Request using JWT adding support for the client_credentials grant type
Explicitly detailed that Data Holders must validate scope for DCR management requests
Updated examples to outline that the cdr:registration scope is required
20/11/2019 1.0.3 Participant Statuses Updated sequence diagrams to explicitly call out the status APIs being called to populate the metadata cache
Updated Status Mapping to clarify that cascading statuses do not cascade to active
07/11/2019 1.0.2 Updated Security Profile Cleaned up out of date statements in client authentication
07/11/2019 1.0.2 Updated Participant Statuses Added Consent Expires column to status mapping to explicitly detail when consent should be cleaned up
07/11/2019 1.0.2 Updated Register API Added tables to add clarification as to who is consuming the APIs, authentication requirements and transport security
06/11/2019 1.0.1 Updated Availability Added clarification on what is expected to change during outages
06/11/2019 1.0.1 Updated Participant Statuses Added Registration cleanup expectations on Software Product status change
31/10/2019 1.0.0 Baseline version 1 This release is the baseline release of the CDR Register design, aligned to the CDS V1.0 release, intended for implementation February 2020
30/10/2019 0.8.0 Updated Client Registration Reverted back Registration flows sequence diagrams to no longer include status checks for the software_id, instead relying on the CDR Register controls
Added non-normative examples for maintenance flows and error scenarios
SSAs will only be issued for active software products
Added Registration Validation section
30/10/2019 0.8.0 Added DCR APIs Added DCR Swagger definitions for Data Holders
24/10/2019 0.8.0 Updated Client Registration Added SSA example with associated JWKS and decoded payload
24/10/2019 0.8.0 Updated Register APIs Added industry parameter on all routes so the associated industry doesn't need to be inferred
Renamed sector to industry to be consistent to the CDS
Removed pagination from GetDataRecipients as this is intended to be called infrequently and cached to CDN
23/10/2019 0.7.0 Updated Client Registration Updated Registration flows sequence diagrams to include a check for Software status
23/10/2019 0.7.0 Updated Participant Statuses Added Facilitate Consent Withdrawal sequence diagram and updated Request for Data Sharing sequence diagram
23/10/2019 0.7.0 Updated Register APIs Added GetDataRecipientsStatus and GetDataRecipients API definitions
16/10/2019 0.6.0 Updated Client Registration Added client credentials POST token example
11/10/2019 0.6.0 Updated Client Registration Corrected grant type urn:ietf:params:oauth:grant-type:jwt-bearer in the example
Corrected grant_types and response_types from string to array of strings
26/09/2019 0.6.0 Updated Client Registration Removed iss_tos_uri as feedback from the community indicated that there is no known use case for this field
Added response details and associated example
Added clarification on Data Holder Authorisation Server requirements
25/09/2019 0.6.0 Updated Client Registration Added sequence diagrams to add clarification to the process
23/09/2019 0.6.0 Updated Client Registration Changed signing algorithm to PS256
Added clarification for client authentication model for Registration endpoints
Added register as the registration URI base path
Changed SSA API lifetime to 10 minutes to ensure sufficient time for batch calls to all relevant Data Holders
23/09/2019 0.6.0 Updated Overview Updated participant statuses to reflect updates to the entity model to accommodate brands
23/09/2019 0.6.0 Updated Overview Updated component diagram to reflect changes for dynamic client registration
23/09/2019 0.6.0 Updated Register APIs Ensured all paths follow kebab-case.
Moved authDetail object out of the endpoint definition. The authDetail object outlines how the Data Holder will call the consent revocation API and therefore, shouldn't be coupled to the endpoint definition
19/09/2019 0.5.0 Updated Client Registration Updated Register Delete endpoint to be optional
19/09/2019 0.5.0 Updated Register APIs Updated Register APIs to reflect discovery of data holder brands and facilitate Dynamic Registration
15/09/2019 0.5.0 Updated Client Registration Updated Client Registration section to detail Dynamic Registration, to reflect updates from GitHub Issue 23
15/09/2019 0.5.0 Updated Security Profile Updated Certificate Management section to reflect updates from GitHub Issue 22
14/08/2019 0.4.0 Updated Swagger Definition Updated JWK schema to conform to RFC 7517
Added redirectUri to whitelist per product
06/08/2019 0.3.0 Addition of Security Profile This section outlines all the security requirements for interacting with the CDR Register
31/07/2019 0.3.0 Updated Swagger definition Removed TermsOfServiceUri, PolicyUri & SupportUri
29/07/2019 0.2.0 Update to Participant Statuses Simplified the validity of Data Recipient Checks to only use Certificate Status and Software Product Status
29/07/2019 0.2.0 Addition of Endpoints Grouped Endpoints and Certificate Management, outlining participant requirements to group and secure endpoints
29/07/2019 0.2.0 Updated Swagger definition Updates include updates to endpoint sets and removing of suspension dates
23/07/2019 0.1.0 Addition of Versioning Outline of Versioning strategy noting that industry collaboration is required for deprecation strategy
23/07/2019 0.1.0 Addition of Participant Statuses Outline of Participant Statuses and expectations on participants within the ecosystem
23/07/2019 0.1.0 Update to Consumer Data Right Register Section Updated component diagram to reflect software product relationship for Data Recipients
09/07/2019 0.1.0 Update to Consumer Data Right Register Section Updated component diagram to reflect Identity Provider requirements for Data Recipients
08/07/2019 0.1.0 Update to Consumer Data Right Register Section Provided ecosystem component diagram with responsibilities of each participant
08/07/2019 0.1.0 Addition of Certificate Management Section Outline of Participant Certificate Issuance and Management expectations
03/07/2019 0.1.0 Addition of Availability Section Outline of Participant Availability expectations
30/06/2019 0.1.0 Addition of Client Registration Section Outline of Client Registration Process
30/06/2019 0.1.0 Addition of change log This change log was added to the standards documentation