Australia’s Consumer Data Right (CDR) was enacted to give consumers more control over their personal data. At first, CDR was introduced in banking, where consumers can choose to share their existing banking data (such as transaction history, interest rates, and more) between different accredited parties. What makes CDR different from, for example, Open Banking directives, is that it takes sharing data to the next level and does not stop at banking. The energy sector is the next market that will be affected by CDR. Consumers will be able to transfer their data from an existing energy provider to a prospective provider or product comparison tool. The telecommunications sector will also be required to adopt CDR standards.
All parties that take part in the CDR environment are required to be compliant with the system. CDR ensures that user experience guidelines and security requirements are met so that consumers can consciously decide which data they wish to share, with the assumption that their personal information is handled as securely as possible.
More choice for the consumers
Consumers can share their data with accredited third-party providers, enabling those providers to create new products or recommendations that are tailored to a specific customer. Consumers will also be able to easily compare different products and services. All markets affected by the CDR directive benefit from competition in the marketplace which leads to innovation, better products and better services.
Australian Government created CDR standards based on existing security frameworks such as OAuth and OIDC. Consumers can decide if they want to share their personal data, who to share it with, what to share, and when to stop sharing their information. All accredited third-party providers must comply with the guidelines to be able to participate in the CDR environment.
Below, you can see a diagram of the components (and participants) that exist within the CDR environment among with some of example APIs they need to provide to fulfill their responsibilities. To learn more about each component (participant) and their responsibilities, see the participants section of this article
The data registry is responsible for holding information on every registered and accredited data recipient and data holder. Data holders provide their APIs that data recipients can call in order to get information about consumers. Data recipients register within the data holder’s authorization server using OAuth 2.0 Dynamic Client Registration and also communicate with the data holder’s authorization server to request authorization and tokens. Authorization servers redirect consumers to data holder’s consent application to enable consumers to decide whether they want to share their data or not. After the authorization and authentication happens for data recipients, they can request data from data holders.
To learn more about each of the participants and what CDR process looks like, see the following sections of this article:
There are several participants in the Consumer Data Right system and each of them fulfills a different purpose and face different requirements.
The regulators are people who are responsible for developing and enforcing the standards for CDR. It is Australian Government and its parts who are responsible for setting up the system. The process is led by Australian Treasury among with the Australian Competition and Consumer Commision (ACCC) and the Office of the Australian Information Commissioner (OAIC). Data standards are developed by the Data Standards Body (DSB) part of the Australian Treasury.
The ACCC peforms as an important role of CDR Registrar. It is responsible for maintaining public data registry with all registered and accredited data recipients and data holders.
If you are trying to get accredited, you can use CDR mock-register for development and testing CDR solutions.
In CDR, the consumers are people who share their personal information between different parties. They are responsible for providing their consent on sharing the data. They decide if they want to share their personal information with a particular recipient. They control what is shared, when it is shared, and when their consent is revoked. The consumer is the central point of CDR as the system is designed to provide the best possible user experience and as highest level of security for consumers data as possible.
Accredited data recipients
Accredited data recipients are providers that receive consumers' personal information after the consumer grant their consent. The recipients can only use data for the purpose and within the scope that was granted in consumers consent.
Register as data recipient
To register as a data recipient, see CDR becoming an accredited data recipient article.
Behind a registered data recipient there is a software product that may be a product comparison tool or an application for personal budget management, and much more.
Data holders are entities that hold consumer data. It may be, for example, a bank or an energy provider. Data holders must be registered within the CDR environment and they are required to share consumers data with a nominated and accredited data recipient after the consumer gives their consent for the personal information to be shared.
Data holders must meet a vast number of compliance requirements such as:
Consumer experience standards that ensure CDR elements are consistent for consumers.
Information security profile that consists of low-level security guidelines such as, for example, encryption or how the tokens are transferred.
API standards that provide instructions on how data holder’s application programming interfaces (APIs) must be built.
Non-functional requirements that include minimum availability periods for data holders' services, maximum traffic expectations, data quality requirements, and more.
To learn more about the compliance requirements for data holders, see CDR data standards.
Australian Government states that all data holders must also meet IT requirements. Any applications and websites serving as data holders must be designed to include the consumer authorization process. The consumers must be able to see and manage their data authorization and include the ability for the consumer to withdraw their consent.
CDR security profile provides security requirements for data holders to ensure that consumers data is safe and no unauthorized party can access it. The security profile, among other tasks, requires the data holder:
To enable data recipients to register within the data holder using OAuth 2.0 Dynamic Client Registration
To communicate consent requirements between data recipients' software products and data holders using authorization request objects.
To implement solutions for scopes and claims, participant statuses, transaction security, and many more.
Because of the vast number of security requirements put on data holders and the importance of those rules for the consumers data security, data holders are, in fact, required to implement a whole OAuth, OIDC, and FAPI compliant authorization server.
Where Cloudentity steps in
Cloudentity is an OAuth 2.0, OIDC, and FAPI compliant platform for application and API access control. With its advanced authorization, governance, and consent management capabilities it serves as a tool that can offload data holders from having to implement all security profile requirements. Cloudentity enables data holders to maintain a Zero Trust policy by ensuring that contextually aware authorization happens for any API, service, or transaction. It keeps consumers personal data secure.
CDR collection and use consents guidelines provide rules for gathering consents from consumers. For example, when a consumer is asked to provide their consent:
Consent applications must present consent information to the consumer in a way that is concise and if appropriate with visual aids so that the consumer can make a conscious decision whether they wish to grant their consent or not.
The consumer must be able to choose the types of CDR data to which the consent applies to.
Data holders must use data language standards to describe data clusters and permissions in consumer-facing interactions.
Consumer must be able to manage and withdraw their consents at any time.
Cloudentity’s consent page and user portal
Cloudentity provide built-in consent page and consent management (user) portal. Data holders can integrate with Cloudentity’s consent page that is presented to consumers after the call to Cloudentity’s
/authorizeendpoint. The consumers can see the data they are asked to share and give or deny their consent. Cloudentity user portal provides consumers with a possibility to manage their consents. The consumers are able to see which consents are granted to which data recipient and manage or withdraw their consent.
Cloudentity delivers an OpenBanking Quickstart GitHub project which was originally created to provide a sample Open Banking consent applications but is now adjusted so it can be used for CDR integration by data holders.
Simplified CDR flow
The diagram and the flow assumes the OAuth authorization grant type is used.
Data recipient registers its software product (client application) within data registry to become an accredited data recipient.
Signed Software Statement Assertion
When data recipients register within the data registry, they request signed software statement assertion (SSA) for their software product. SSA is a JSON Web Key Set that is later on used to register the software product as a client application within data holder’s authorization server using Dynamic Client Registration (DCR).
Data holder registers within data registry to become an accredited data holder.
Data recipient uses DCR and its SSA to register within data holder’s authorization server.
Authorization server pulls JWKS from data registry using SSA to verify if the data recipient is accredited.
A consumer accesses a data recipient’s software (client application).
The client application sends a requests authorization from the data holder’s authorization server using the
Authorization server verifies the request and redirects the user to the consent application.
Consent application displays consent to the consumer.
The consent screen provides all of the details that are needed for the consumer to make a conscious decision whether to grant consent or not.
The consumer grants consent.The consumer may also deny the consent in this step, but for demonstration purposes, it is accepted.
Consent application passes the result to the authorization server.
The authorization server responds with an authorization code to the data recipient’s client application.
Data recipient’s client application requests token from the authorization server using the authorization code it received in the previous step.
Authorization server verifies the request and responds with access token (and optionally, an ID token and a refresh token).
Data recipient’s software is now able to call data holder’s APIs to request data on the consumer.
Data holder responds with the requested resources.
CDR Integration guides
Feels like diving deep into all the CDR specifics and integrations? We have detailed guides to help you navigate the CDR journey with ease.