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:
- drafting rules to implement and govern the CDR in each sector;
- accrediting entities to receive data;
- managing an online register of accredited data recipients and data holders;
- providing education and guidance on the CDR;
- recommending to government future sectors to be brought within the CDR; and
- compliance and enforcement activities.
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:
- For transparency, if you work at or are associated with an organisation with an interest in the Consumer Data Right, please indicate this in your response.
- Please ensure you are aware of and compliant with any social media guidelines or internal processes for response set by your organisation before providing feedback.
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.
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.
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.
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 Applications consuming CDR data.
Data Holder
Component | Responsibility |
---|---|
Consent Authorisation 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. Storing of authorisations |
Identity Provider | Provides identity services to the Data Holder’s platform for identifying Accredited Data Recipients and the CDR Register |
Standards Platform | Exposes banking, consumer and product data to Accredited Data Recipients as per the Consumer Data Standards: https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-banking-apis https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-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: Cache Refresh Metadata Request |
MetaData Update & Reporting | Provides functionality to facilitate Metadata Update requests from the ACCC as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#metadata-update |
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 |
API | Responsibility |
---|---|
Banking API | API exposing banking data as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-banking-apis |
Common API | API exposing common data as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-common-apis |
InfoSec API | API exposing endpoints to facilitate the InfoSec profile as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#end-points |
Registration API | API exposing dynamic registration endpoints as described at Dynamic Client Registration |
Admin API | API exposing facilitating metadata refresh and exposing admin data as per https://consumerdatastandardsaustralia.github.io/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 which consumes consumer and product data from Data Holders as per the Consumer Data Standards: https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-banking-apis https://consumerdatastandardsaustralia.github.io/standards/#consumer-data-standards-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. Storing of consents |
MetaData Cache | Cache of discovered Data Holders within the CDR ecosystem. Caching rules and logic are described at: Cache Refresh Metadata Request |
MetaData Update | Provides functionality to facilitate Metadata Update requests from the ACCC as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#metadata-update |
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 |
API | Responsibility |
---|---|
InfoSec API | API exposing the revocation endpoint to facilitate bi-directional consent revocation, as per the Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#end-points |
Admin API | API exposing facilitating metadata refresh and exposing admin data as per https://consumerdatastandardsaustralia.github.io/standards/#admin-apis |
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 facilitate Dynamic Client Registration 4. Provides public JWKS to assert SSAs are trusted by the CDR Register 5. Identifies when participants within the ecosystem change significantly, notifying relevant Data Holders and Accredited Data Recipients of those changes via the MetaData Update calls on the Admin API Details on this process is outlined at: Cache Refresh Metadata Request
API | Responsibility |
---|---|
Discovery APIs | 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 following methods:
Phase 1 | Manually distributed to an approved technical representative for the Accredited Data Recipient |
Phase 2 | Retrievable via an API exposed on the CDR Register |
Namespacing
The design will conform to [RFC7591] and 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 statementvalue: "cdr-register" |
|
iat | Required | Issued at time claim | |
exp | Required | Expiration Time claim | |
jti | Required | JWT ID claim | |
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 per https://consumerdatastandardsaustralia.github.io/standards/#end-points | |
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: https://consumerdatastandardsaustralia.github.io/standards/#authorisation-scopesThe 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
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
- SSAs will be signed by the Register
- Register public keys will be exposed on a dedicated JWKS URI endpoint
- CDR Register JWKS will be exposed on an unauthenticated endpoint, using TLS. This allows for distribution via CDN, increasing tolerance for Register outage
- Endpoint details will be provided to participants during the onboarding process
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",
"request_object_signing_alg":"PS256",
"software_statement":…
}
{
"signature":...
}
To register a Software Product at 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 [FAPI-RW] Section 8.6.
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 overwrites a 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 | Optional | Algorithm which the ADR expects the id_token to be signed with, if an id_token is returnedSupported values as constrained by FAPI-RW |
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 HolderSupported values as constrained by FAPI-RW |
software_statement | Required | Software statement assertion issued by the CDR Register |
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.
Error codes returned for invalid registration requests can be found at: Error Codes
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",
"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
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 | 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
- During registration management requests, Data Holders must validate the scope of access tokens provided matches
cdr:registration
- Registration endpoints will be exposed under the InfoSecBaseUri, as described at: Endpoints
Authorisation Server Requirements
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
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
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
- Suspended or revoked by the ACCC
- 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 referred to, 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 |
- Disclosure of CDR data MUST be in response to valid requests in accordance with the CDR rules and standards
- The status of an Accredited Data Recipient Brand does not impact data sharing and withdrawal of consent due to the cascade rules outlined above
- When an Accredited Data Recipient status is Suspended, Revoked or Surrendered the Software Product status cannot be Active
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
Request for Consent Withdrawal: Checking Validity of Accredited Data Recipient and associated Software Product
Pre-requisites: SSL connection has been established between all parties
ADR 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:
- The Registrar will issue the Accredited Data Recipient all required certificates
- The Accredited Data Recipient's status will be set to 'active'
- The Accredited Data Recipient will be able to register their software products with Data Holders within the ecosystem
- 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:
- 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'
- The CDR Register will initiate the metadata cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache of software product statuses within the specified timeframe
- The Data Holder's responsibilities with this suspended Data Recipient are outlined at Data Holder Responsibilities
ADR Reactivated
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:
- The Registrar will update the CDR Register to change the Accredited Data Recipient's status (and status of all associated software products) to 'active'
- The CDR Register will initiate the metadata cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache of software product statuses within the specified timeframe
- The Data Holder's responsibilities with this reactivated Data Recipient are outlined at Data Holder Responsibilities
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:
- The Registrar will revoke Accredited Data Recipient's client certificates
- The Registrar will update the CDR Register to change the Accredited Data Recipient's status (and status of all associated software products) to 'revoked'
- The CDR Register will initiate the cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache of software product statuses within the specified timeframe
- The Data Holder's responsibilities with this revoked 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:
- The Registrar will revoke Accredited Data Recipient's client certificates
- The Registrar will update the CDR Register to change the Accredited Data Recipient's status (and status of all associated software products) to 'surrendered'
- The CDR Register will initiate the cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache of software product statuses within the specified timeframe
- The Data Holder's responsibilities with this surrendered Data Recipient are outlined at Data Holder Responsibilities
Software Product Status Changes
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:
- The Software Product status will be set to 'active'
- The Accredited Data Recipient will be able to register this software product with Data Holders within the ecosystem
- 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:
- The Registrar will update the CDR Register to change the Software Product’s status to 'inactive'
- The CDR Register will initiate the metadata cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache within the specified timeframe
- 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:
- The Registrar will update the CDR Register to change the Software Product’s status to 'active'
- The CDR Register will initiate the metadata cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache within the specified timeframe
- 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:
- The Registrar will update the CDR Register to change the Software Product’s status to 'removed'
- The CDR Register will initiate the cache update process with all Data Holders within the CDR. Data Holders will be required to refresh their cache within the specified timeframe
- 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
Data Holders and Accredited Data Recipients will be required 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:
- A new Data Holder becomes active
- A new Accredited Data Recipient software product becomes active
- A Data Holder has been surrendered from the CDR
- An Accredited Data Recipient Software Product has been deactivated or removed from the CDR Register
Data Holder Caching of Accredited Data Recipients Software Product Metadata
Metadata Cache Management Metrics
Maximum Cache update period | 6 hours |
Maximum Time between Cache Refresh Metadata Request and call to Metadata API |
5 minutes |
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
The CDR Register Secured APIs will use
Mutual Authentication TLS
[MTLS] as the transport security and the OIDCclient_credentials
grant type authenticationThe CDR Register unsecured APIs will use [TLS] as the transport security with no authentication requirements
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
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
Using the same client authentication approach as the Consumer Data Standard, interactions with and by the CDR Register use private_key_jwt
Client Authentication method as specified at section 9 of [OIDC].
Data Holders MUST support the authentication of the CDR Register using the
private_key_jwt
client authentication methodData Recipients MUST support the authentication of the CDR Register using the
private_key_jwt
client authentication methodData Holders are NOT required to authenticate with the CDR Register. There are no protected APIs available to Data Holders
The CDR Register MUST support the authentication of the Data Recipients using the
private_key_jwt
client authentication methodCDR Register public keys MUST only be obtained from the exposed endpoint exposed for this purpose.
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.
private_key_jwt
CDR Register Access Token Request using Client Authentication
- Access Token will be requested as per the Assertion Framework for OAuth2 Client Authentication profile
- Data Holder and Data Recipient public keys are retrieved from the CDR Register
- Refresh tokens will not be provided for grant_type
client_credentials
- The JWT must contain the following Claim Values :
-
iss
: The issuer claim which contains a unique identifier for the entity that issued the JWT -
sub
: The principal that is the subject of the JWT for client authentication -
aud
: The URL of the end point being invoked -
exp
: The expiration claim that limits the time window during which the assertion can be used -
jti
: The JWT ID claim that provides a unique identifier for the token
When invoking a protected end point, the assertion MUST be sent with the POST
method and MUST include the following parameters:
-
grant_type
: This MUST be set toclient_credentials
-
client_id
: This MUST be set to the ID of the calling client -
client_assertion_type
: This MUST be set to:urn:ietf:params:oauth:client-assertion-type:jwt-bearer
-
client_assertion
: This MUST be set to the digitally signed JWT
CDR Register Calling Participant Admin API using Client Authentication
Non-Normative Example
POST /admin/register/metadata HTTP/1.1
Host: admin.dataholder.com.au
Content-Type: application/x-www-form-urlencoded
client_id=cdr-register&
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": "cdr.register",
"sub": "cdr.register",
"exp": 1516239322,
"aud": "https://admin.dataholder.com.au/admin/register/metadata",
"jti": "37747cd1-c105-4569-9f75-4adf28b73e31"
}
- The CDR Register will expose an endpoint to distribute it's public keys
- The JWT must contain the following Claim Values :
-
iss
: The issuer claim which contains a unique identifier for the entity that issued the JWT -
sub
: The principal that is the subject of the JWT for client authentication -
aud
: The URL of the end point being invoked -
exp
: The expiration claim that limits the time window during which the assertion can be used -
jti
: The JWT ID claim that provides a unique identifier for the token
When invoking a protected end point, the assertion MUST be sent with the POST
method and MUST include the following parameters:
-
client_id
: This MUST be set to the ID of the calling client -
client_assertion_type
: This MUST be set to:urn:ietf:params:oauth:client-assertion-type:jwt-bearer
-
client_assertion
: This MUST be set to the digitally signed JWT
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 Participant Admin APIs | value: cdr-register |
Transaction Security
Please refer to the Consumer Data Standards Transaction Security for Transaction Security details
Participant Endpoints
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 FQDNSecures the following:- Resource endpoint- InfoSec endpoints- Admin endpoints | It will be up to the DH on how these endpoints aresegregated. 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 FQDNSecures the following:- InfoSec endpoints- Admin endpoints | It will be up to the ADR on how these endpoints aresegregated. They may all be on the one domain(so only one certificate required) or could be separated |
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 | Participants will not be able to communicate with the Register |
Impact | Participants will not be able to refresh their metadata caches with up-to-date participant security data |
Impact | Participants will not be able to refresh their metadata caches with new participants |
Expectation | Participants 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 participants will receive a refresh cache notification |
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 ADRs |
Impact | Data Holders will not be able to inform ADRs that consent has been withdrawn |
Expectation | Data Holders will need to continually poll the ADR until recovery. Upon recovery, the consent withdrawal process will need to be executed |
Result | The CDR Register will not be able to communicate with ADRs |
Impact | The CDR Register will not be able to inform the ADRs that they will need to refresh their metadata cache |
Expectation | Accredited Data Recipients will be expected to refresh their metadata cache upon recovery from any outage |
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 DH until recovery Upon recovery, the consent withdrawal process will need to be executed |
Result | The CDR Register will not be able to communicate with the Data Holder |
Impact | The CDR Register will not be able to inform the Data Holder they will need to refresh their metadata cache |
Expectation | Data Holders will be expected to refresh their metadata cache upon recovery from any outage |
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://api.discovery.cdr.gov.au/cdr-register/v1/{industry}/data-holders/brands HTTP/1.1
Host: api.discovery.cdr.gov.au
Accept: application/json
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 |
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://api.discovery.cdr.gov.au/cdr-register/v1/{industry}/data-recipients/brands/{dataRecipientBrandId}/software-products/{softwareProductId}/ssa HTTP/1.1
Host: api.discovery.cdr.gov.au
Accept: application/json
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 |
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://api.discovery.cdr.gov.au/cdr-register/v1/{industry}/data-recipients/brands/software-products/status HTTP/1.1
Host: api.discovery.cdr.gov.au
Accept: application/json
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://api.discovery.cdr.gov.au/cdr-register/v1/{industry}/data-recipients/status HTTP/1.1
Host: api.discovery.cdr.gov.au
Accept: application/json
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://api.discovery.cdr.gov.au/cdr-register/v1/{industry}/data-recipients HTTP/1.1
Host: api.discovery.cdr.gov.au
Accept: application/json
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",
"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: string
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",
"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: string
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",
"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: string
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",
"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 which the ADR expects id_token to be signed with, if an id_token is returned |
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 |
application_type | web |
id_token_signed_response_alg | PS256 |
request_object_signing_alg | PS256 |
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",
"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 |
---|---|---|---|
10/12/2019 | 1.0.5 | Updated Security Profile | Added Register Endpoint section detailing Register access token retrievalUpdated 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 requiredUpdated 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 OIDCUpdated 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 fromUpdated 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 typeExplicitly detailed that Data Holders must validate scope for DCR management requestsUpdated 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 cacheUpdated 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 controlsAdded non-normative examples for maintenance flows and error scenariosSSAs will only be issued for active software productsAdded 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 inferredRenamed sector to industry to be consistent to the CDSRemoved 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 exampleCorrected 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 fieldAdded response details and associated exampleAdded 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 endpointsAdded register as the registration URI base pathChanged 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 |