Authorization Basics

Consumer Data Right Overview

This article provides an overview of the Australian Consumer Data Right (CDR) system. Learn what CDR is and what kind of problems it aims to solve. Learn what parties exist within CDR system. Get familiar with a simplified process of a consumer granting their consent for using their data by third-party applications.

CDR overview

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.

Benefits

  • 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.

  • Data security

    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.

CDR components

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

CDR process

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.

Learn more

To learn more about each of the participants and what CDR process looks like, see the following sections of this article:

Participants

There are several participants in the Consumer Data Right system and each of them fulfills a different purpose and face different requirements.

[mermaid-begin]
classDiagram class Data Registry Data Registry: +GET /data-holders Data Registry: +GET /data-recipients Data Registry: +and more class Data Holder Data Holder: +GET /banking/accounts Data Holder: +GET /banking/products Data Holder: +GET /energy/plans Data Holder: +GET /energy/accounts Data Holder: +and more class Data Recipient class SoftwareProduct class Consent Application Consent Application: +GET /?login&state Consent Application: +POST /?login&state class Authorization Server Authorization Server: +POST /cdr-arrangement/{login}/accept Authorization Server: +POST /cdr-arrangement/{login}/reject Authorization Server: +POST /token Authorization Server: +and more Data Registry <|-- Data Holder Data Registry <|-- Data Recipient Data Holder o-- Consent Application Data Holder o-- Authorization Server Data Recipient o-- SoftwareProduct

Regulators

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.

Mock registry

If you are trying to get accredited, you can use CDR mock-register for development and testing CDR solutions.

Consumers

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.

To be able to receive customers' data, recipients must become accredited by the (ACCC).

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

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.

Security profile

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:

Authorization server

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.

Consumer consents

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.

  • and more.

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 /authorize endpoint. 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.

[mermaid-begin]
sequenceDiagram autonumber participant user as Consumer participant tpp as Data recipient participant server as Data holder's authorization server (Cloudentity) participant app as Consent application participant dh as Data holder participant dr as Data registry tpp->>dr: Gets registered dh->>dr: Gets registered tpp->>server: DCR (with SSA) server->>dr: Pull JWKS to verify SSA user->>tpp: Access tpp->>server: /authorize server->>app: Redirect user to consent application app->>user: Display consent user->>app: Give/deny consent app->>server: Pass consent result server->>tpp: Authorization code tpp->>server: Call /token with authorization code server->>tpp: Return token tpp->>dh: Call API with token dh->>tpp: Return consumer's data
  1. 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).

  2. Data holder registers within data registry to become an accredited data holder.

  3. Data recipient uses DCR and its SSA to register within data holder’s authorization server.

  4. Authorization server pulls JWKS from data registry using SSA to verify if the data recipient is accredited.

  5. A consumer accesses a data recipient’s software (client application).

  6. The client application sends a requests authorization from the data holder’s authorization server using the /authorize endpoint.

  7. Authorization server verifies the request and redirects the user to the consent application.

  8. 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.

  9. The consumer grants consent.The consumer may also deny the consent in this step, but for demonstration purposes, it is accepted.

  10. Consent application passes the result to the authorization server.

  11. The authorization server responds with an authorization code to the data recipient’s client application.

  12. Data recipient’s client application requests token from the authorization server using the authorization code it received in the previous step.

  13. Authorization server verifies the request and responds with access token (and optionally, an ID token and a refresh token).

  14. Data recipient’s software is now able to call data holder’s APIs to request data on the consumer.

  15. 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.