Introduction
Authorisation and consent are central to the Consumer Data Right (CDR). Accredited Data Recipients (ADRs) and Data Holders (DHs) must obtain consent from the consumer before sharing consumer data.
An ADR cannot infer consent, or rely on an implied consent. Consent must be voluntary, express, informed, specific as to purpose, time limited, and easily withdrawn.
Data Holder (DH), Accredited Data Recipient (ADR) and Customer (consumer) are defined as part of the Consumer Data Standards (CDS). See CDS CDR federation. The terms customer and consumer are used interchangeably in the CDR context.
Strict standards apply for authentication of all parties involved in sharing of consumer data. There are stringent requirements for maintaining the security of transactions.
CDR information security builds upon the foundations of the Financial-grade API Read Write Profile (FAPI-RW) and other standards relating to Open ID Connect 1.0 (OIDC). The proposed authentication flow is the redirect with one-time password (OTP) model.
CDR authentication, consent and transaction security all depend on OIDC standards. The authorisation request object, scopes and claims referred to in the CDS are defined in the OIDC standards.
See:
For DSB videos on consent, See Consent Flow Part 1 and Consent Flow Part 2.
The diagram below shows a simplified consent sequence. The video Consent Flow Part 1 walks through this sequence.
- ADR requests consumer's consent to share data
- Consumer consents
- ADR requests data access from DH
- DH requests authentication from consumer
- Consumer authenticates
- DH requests authorisation to share data from consumer
- Consumer authorises data sharing
- DH shares data with ADR
- ADR provides service with data to consumer
For details of the consent sequence, with interactions between consumer, ADR, and DH, see Consent sequence diagrams. The video Consent Flow Part 2 walks through these sequence diagrams.
Authentication
The DH authenticates a Customer as part of an authorisation process initiated by an ADR, and issues an authorisation for that ADR to access the Customer's data via published APIs. The DH must maintain an Authorisation end point for this purpose.
When DHs call ADR APIs, the DH authenticates itself with a signed JWT.
When ADRs call DH APIs, the ADR authenticates itself with a signed JWT.
See:
Transaction security
Digital certificates required for DH and ADR authentication are issued and managed by the CDR Register Certificate Authority. See CDS Transaction security.
Authorisation
When an authenticated Customer provides a specific consent, the ADR is authorised to receive the specified Customer data from the DH.
Consent scopes and claims
Consent details are communicated between the ADR and DH via the OIDC authorisation request object. Consent details are specified in the form of OIDC scopes and claims.
A customer can provide multiple consents, each related to sharing a different set of data. See Concurrent consent below.
Concurrent consent
Concurrent consent refers to an ADR establishing multiple active consents with a DH on behalf of a consumer. The consents may have different scopes, related to different sets of data.
See:
Consent dashboards
To obtain consent to share data, both ADRs and DHs must provide a dashboard that allows the Customer to provide consent for specific data to be shared. See CDR Rules subdivision 1.4.3, sections 1.14 Consumer dashboard—accredited person and 1.15 Consumer dashboard—data holder.
A Customer consent applies to specific Customer data. The CDR Rules require that the Customer must be fully informed regarding the data that is shared according to the consent.
The DH displays active consents on the consumer dashboard.
For authentication flow and on dashboards, the DSB recommends brand name be used. However, the rules require the legal entity name to be used in the authorisation flow.
See the CX Guidelines Consent chapter for guidelines on the customer dashboard consent interface.
See Dashboards.
Changing or amending consent
A consent cannot be changed. To achieve the effect of changing a consent, a consent is revoked, and a new consent is created, linked to the previous revoked consent, via a common arrangement ID. This process is often referred to as 'amending consent' in CDR discussions.
The CX guidelines provide for a consent edit button on the ADR dashboard.
See CDS Identifiers and Types, CDR Arrangement ID.
Because it is technically a new OAuth consent, the amended consent can be completely different from the original. All aspects can be changed, or a single attribute can be changed. For example, a consumer may simply change the duration of the consent.
When a consent is amended, the method of signifying the change is at the Data Holder's discretion. See CDS Amending Authorisation Standards.
For the new consent to be associated with the existing arrangement, a PAR (Pushed Authorisation Request) is used and the arrangement ID is passed.
Expiry, withdrawal and revocation of consent
A consent may be current, or expired. A consent may expire for a number of reasons. These are listed in the CDR Rules. See:
- CDR Rules main section, Subdivision 4.3.2B - Withdrawing consents, 4.13 Withdrawal of consents, and notifications
- CDR Rules main section, Subdivision 4.3.2C - Duration of consent, 4.14 Duration of consent
A consent expires when the period of consent concludes. It also expires when the consumer withdraws, or revokes consent.
When a consent expires, the Consumer Data Standards do not specifically require an associated access token to become invalid. It is valid to request a consent with a zero second duration, specifically for once off collection. However access tokens must have a short life span.
When a consent has expired, no new associated access tokens are created. However existing access tokens should be honoured.
Withdrawing consent
A Customer can withdraw consent, using either the DH or ADR dashboard.
See:
- CDR Rules main section, subdivision 4.3.2, section 4.11(3)(g).
When a consumer withdraws consent at the DH dashboard, the DH should attempt to inform the ADR.
When a consumer withdraws consent at the ADR dashboard, the ADR should attempt to inform the DH.
A customer may withdraw consent by other means. For example, a consumer may withdraw consent by phone or in writing. The ADR or DH from whom the consumer withdraws consent should attempt to inform the other party to the consent, and indicate the withdrawal of consent on the consumer dashboard.
See:
- CDR Rules, subdivision 1.4.3, 1.14 Consumer dashboard - accredited person
- CDR Rules, subdivision 1.4.3, 1.15 Consumer dashboard - data holder.
In some cases an outage or other event may prevent an ADR or DH communicating withdrawal of consent. It is the responsibility of the ADR and the DH to ensure that consent is current before sharing data. See Maintaining synchronisation of consents after outages.
The DH maintains records of withdrawals of authorisations in accordance with CDR Rules, Part 9, subdivision 9.3.1 - Reporting and record keeping, section 9.3(1)(b).
For guidance on withdrawal of consent, see Guidance on revocation or withdrawal of consent.
De-identification and deletion
De-identification and deletion rules are triggered when an event makes shared data redundant. Removal of access to an account could be such an event. Withdrawing consent, or deselecting an account for sharing in the consumer dashboard, are among the events that may remove access. However, if there is an ongoing consent, or another reason for data retention, then de-identification or deletion of account data is not required.
See:
- CDR Rules, main section, subdivision 1.4.5—Deletion and de‑identification of CDR data
Joint accounts
When two or more Customers have joint authority over an account, one of the account holders can withdraw consent for sharing of data related to the account, even if consent is authorised by another of the account holders.
Eligible consumers
A consumer may become no longer eligible for a number of reasons. For example if a banking consumer closes all online accounts with the DH, the consumer is no longer eligible regarding any consents with that DH.
When a consumer is no longer eligible, the DH is obliged to expire any consents of that consumer.
Browser support
From a CX perspective there are no requirements on which browsers must be supported. At a minimum the supported browsers should be consistent with the Data Holder's existing digital banking channels.
DH and ADR notification and record keeping
DHs are obliged to notify ADRs when a consent is withdrawn. The consumer may withdraw the consent. The DH may expire a consent if the consumer is no longer eligible. An ADR should notify the DH when the consumer withdraws consent via the ADR.
The rules do not specify an obligation to notify the ADR when the authorisation expires by reaching the end of the sharing period.
In some cases DHs are required to notify consumers when an authorisation expires:
- When an authorisation sharing data from a joint account expires. See CDR Rules, main section, part 4A Joint accounts, rule 4A.14.
- When an authorisation given by a secondary user expires, the account holder must be notified. See CDR Rules, main section, part 4, division 4.4, rule 4.28(2).
- As per privacy safeguard 10, the DH should notify the consumer via the dashboard when the CDR data was last disclosed.
The DH displays active consents on the consumer dashboard, which also effectively indicates when consents are no longer active.
The CX Guidelines recommend that DHs provide a 'CDR Receipt' to the consumer in writing, other than through the dashboard, when authorisations are:
- established
- withdrawn
- expired
- amended. See Changing or amending a consent, above.
A DH must keep and maintain records of withdrawals of authorisations in accordance with CDR Rules, 9.3(1)(b). Records should include how the withdrawal was requested by the customer.
References
See:
- CDR Rules (Competition and Consumer (Consumer Data Right) Rules 2020)
- CX Guidelines, Consent
- Maintaining synchronisation of consents after outages
- Concurrent consent
- CDS authorisation scopes
- Security Profile, End Points
- Requirements for Data Recipient implementations
- Revoking Consent
- Updating Register Meta Data and Client Registration
- Pushed Authorisation End Point
- CDS CDR arrangement ID
- Consumer Experience Standards
- Get Balances For Specific Accounts, Responses
- Get Scheduled Payments For Specific Accounts
Subsections
Comments
1 comment
This document contains the statement of: "When a consumer is no longer eligible, the DH is obliged to withdraw any consents of that consumer."
This appears to be inaccurate. When a Consumer becomes ineligible the ability to transfer CDR Data may be stopped but the "withdrawal" of consents (i.e. revocation) does not appear to be specified in the Rules or Standards? Triggering revocation on ineligibility, particularly in Energy, is likely to be problematic as a Consumer can oscillate between eligible and ineligible quite quickly.
Please sign in to leave a comment.