The Consent Amendment Process of Australian CDR Specification.
Australian Consumer Data Rights rules (CDR) has improved its consumer consent (Customer’s preference to share his/her own data with a 3rd party) management process to include the ability to update an existing consent arrangement.
Earlier, if you want to update your current data sharing arrangement you need to remove it first. Then you need to create a brand new consent arrangement with necessary changes. You were not able tinker on the existing.
Treasury (earlier ACCC)has introduced a new attribute called “cdr_arrangement_id” to the OAuth 2.0 back channel interaction to identify an existing data sharing agreement between Accredited Data Recipient (ADR) and Data Holder (DH) against a consumer. There can be multiple data sharing arrangement under a single a “cdr_arrangement_id”.
Following definition is extracted from CDS specification 1.9.0.
The CDR Arrangement ID is a unique string representing a consent arrangement between a Data Recipient and Data Holder for a given consumer.
The identifier MUST be unique per customer according to the definition of customer in the CDR Federation section of this profile.
The Data Holder MUST provide the CDR Arrangement ID as the claim
cdr_arrangement_idin the Token End Point response and Token Introspection End Point response.
As described by the specification the way the actual value is generated is up to the data holder. But it needs to follow design guidelines shown below.
- The CDR Arrangement ID MUST be unique to a Data Holder
- The CDR Arrangement ID MUST be non-guessable and must not identify a consumer
- A CDR Arrangement ID SHOULD be generated using an algorithm that reduces the chances of collision
- A CDR Arrangement ID MUST be static across consents within the one sharing arrangement (e.g. across consent renewal and re-authorisation)
“cdr_arrangement_id” attribute will first start appearing on the token response after a successful consent flow.
Data holder is required to maintain generated cdr_arrangement_id locally and link that to the latest data sharing arrangement.
Concurrent consent allows the same Accredited Data Recipient (ADR) software product to establish more than one active consent with a Data Holder (DH) on the consumer’s behalf.
The purpose is to allow consents with different scopes, use cases or purposes to be established under one ADR application, so that ADRs can correctly observe the Data Minimisation principle.
This is achieved technically through the establishment of separate CDR Arrangement IDs for each individual consent as shown below.
ADR requesting a change in the data sharing arrangement (consent)
ADR sends a request to the Pushed Authorization Request (PAR) with the “cdr_arrangement_id” and the new consent scope and sharing duration that needs to be updated as shown below.
The response of the PAR request would look like below.
The “request_uri” uniquely identify the new consent amendment scope.
ADR will invoke the OAuth2.0 authorize endpoint with the “request_uri” after the PAR endpoint interaction that was described above.
When this request is made the consent flow is initiated. Data Holder (DH) will load the registered authorization request identified by the “request_uri”. Authorization request has an “cdr_arrangement_id” defined which indicate that there is an existing data sharing agreement. Data Holder need to compare the scope and sharing duration of the existing data sharing arrangement with the new amendment request and highlight the changes on the consent flow UI. Changes are highlighted in “new” tag below.
Following rules apply to the Consent flow related to the consent amendments.
- At customer profile selection
DH should omit the profile selection step and assume the customer profile associated with the existing authorization. DH may indicate which profile the authorization relates to during the authorization process
- At account selection
DH must pre-select accounts that were associated with the previous authorization provided these accounts remain eligible and available. DH may allow these accounts to be amended. DH may provide information regarding the pre-selection of accounts. DH must indicate where a dataset is being added to an authorization or a disclosure duration is being amended DH may apply this standard to other changing attributes, but this MUST ONLY apply where the attribute in the new authorization differs to that of the previous authorization. How a changed attributed is signified is at the DH’s discretion.
Removing an existing data sharing arrangement (consent) and informing relevant parties
Removal or revocation of an existing consent can happen at ADR (Accredited Data Recipient) or Data Holder (DH). In order to inform the other party about the revocation, the CDR Arrangement Management Endpoints (CARE) is used. CDR Arrangement Management Endpoint need to be implemented by both parties. Data Holders implements the CARE endpoint as the CDR Arrangement Revocation endpoint and the URI will be published on the OIDC Discovery endpoint response as shown below.
The “cdr_arrangement_id” is used to uniquely identify which consent should be revoked. This makes the communication of revocation much more cleaner and straightforward.
For Data Holders to determine the base URI to invoke when informing the revocation, a new claim is introduced with the software statement assertion known as “recipient_base_uri” as shown below.
