Authorization Basics

12 mins read

Consumer Data Right

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.

What Consumer Data Right Is

Australia’s Consumer Data Right (CDR) gives consumers greater access and control over their data, improving their ability to compare and switch between products and services. It encourages competition between service providers, leading to better prices and more innovative products and services. The CDR is rolled out industry-by-industry, starting with the banking sector and followed by the energy and telecommunications sectors. To build a standardized ecosystem of data sharing agreements, it is important to have explicit consent from consumers before data access is provided, and to use secure application programming interfaces (APIs) for third parties to access customer data with the customer’s consent. This momentum is being replicated worldwide with the “Open Banking” initiative and similar legislation in other countries.

Get OAuth, Consent, and API Security for CDR

Cloudentity comes with instantly applicable and CDR-specific authorization server profile that can make your solution instantly compliant with the CDR requirements.

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.

Consumer Data

Financial institutions within the industry sectors that own the consumer data are also referred to as Data Holders. The Consumer Data Right (CDR) aims to provide greater choice and control for Australians over how their data is used and disclosed. CDR requires all Australian Data Holders to:

  • Open up the consumer data they hold to accredited third parties
  • Attain consent of the consumer before sharing their data with accredited third parties
  • Apply Strong Customer Authentication (SCA)

These industries, for example, need to open secure application programming interfaces (APIs) for accredited third parties to access customer data with the customer’s consent.

Secure & Trusted Data Sharing in OpenAPI Economy

Using standardized APIs and then enabling access to those with consumer consent using established industry-standard secure protocols including OAuth 2.0 and OIDC, banks, and authorized third-parties can develop innovative products and solutions for consumers and businesses. It’s a new era for Security, Privacy, and Consent in all industries that hold customer-generated data sets.

CDR Components

Below, you can see a diagram of the components and participants that exist within the CDR environment along with some 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:

Simplified CDR flow

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 Register Data Register: +GET /data-holders Data Register: +GET /data-recipients Data Register: +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 Register <|-- Data Holder Data Register <|-- 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 performs a 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; 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.

Cloudentity as CDR Enabler

Cloudentity provides the capabilities required by Data Holder organizations to meet the CDR Security profile requirements and securely authenticate end users, collect required consents, onboard accredited third parties to request data, manage the consumer consent, and verify the consumer authorization before data is shared with accredited Data Recipients. Cloudentity also facilitates Data Holders to allow its consumers to manage their data sharing consent agreements securely. In a nutshell, the Cloudentity platform facilitates and accelerates the Data Holder organization’s journey to expose their data APIs securely with consumer consent as required by Consumer Data Right.

The CDR Security profile builds upon the foundations of the Financial-grade API Read Write Profile FAPI-RW-Draft, Financial-grade API Advanced Profile FAPI-1.0-Advanced and other standards relating to Open ID Connect 1.0 OIDC. Keeping up with the evolving advanced specifications in OIDF space can be a challenge for any organization and Cloudentity takes on this challenge. It allows organizations to completely focus on the business data APIs for banking and energy that need to be exposed as per CDR specifications.

Adopting Cloudentity accelerates the entire effort to achieve CDR-compliance drastically and allows faster time to market. Cloudentity solution offers a highly performant, multi-tenant advanced FAPI compliant and certified authorization server built on open standards and compatible with advanced OAuth 2.0 & OIDC specifications. Cloudentity also provides a rich set of APIs that facilitates consent collection & management for the Data Holder to implement the CDR recommended safe and secure customer journey experiences using various digital channels.

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.

Updated: Sep 8, 2023