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.
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.
Missing image
 |
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.
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:
To support all client authentication flows specified by the OpenID Connect (OIDC) specification and constrained by the Financial-grade API (FAPI) specification.
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 provide ID tokens according to the OIDC specification and access tokens as specified in the OAuth 2.0 Authorization Framework specification
To implement solutions for scopes and claims, participant statuses, transaction security, and many more.
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 SecureAuth steps in
SecureAuth 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. SecureAuth 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.
SecureAuth's consent page and user portal
SecureAuth provide built-in consent page and consent management (user) portal. Data holders can integrate with SecureAuth's consent page that is presented to consumers after the call to SecureAuth's /authorize endpoint. The consumers can see the data they are asked to share and give or deny their consent. SecureAuth 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.
SecureAuth 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
/authorizeendpoint.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.
SecureAuth as CDR Enabler
SecureAuth 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. SecureAuth also facilitates Data Holders to allow its consumers to manage their data sharing consent agreements securely. In a nutshell, the SecureAuth 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 SecureAuth 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 SecureAuth accelerates the entire effort to achieve CDR-compliance drastically and allows faster time to market. SecureAuth 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. SecureAuth 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.