Updates to 'Revoking consent' Standards

[CDR-API-Stream]

Description

The latest rule amendments introduced the following changes associated with notifying participants of expired consents:
(highlights with '+' added for emphasis)

4.18AA  Notification of data holder or accredited data recipient if collection consent expires
  (1) This rule applies if:
    (a) an accredited person has made a consumer data request to a CDR participant, 
        based on a collection consent given under this Division relating to particular 
        CDR data and that CDR participant; and
    (b) the request has not been completely resolved; and
+   (c) the consent expires for any reason.
  (2) The accredited person must notify:
    (a) if the CDR participant is a data holder―the data holder, in accordance with 
        the data standards, that the consent has expired; and
    (b) if the CDR participant is an accredited data recipient―the accredited data recipient
        as soon as practicable that the consent has expired.

and

4.26A  Notifications of expired authorisations
  If an authorisation to disclose particular CDR data to an accredited person is withdrawn 
+ or otherwise expires, 
  the data holder must notify the accredited person in accordance with the data standards.

Area Affected

In relation to these rules, the Standards currently state, respectively:
(bold added for emphasis)

Revoking consent

Data Recipient Software Products MUST use the Data Holder's CDR Arrangement Revocation End Point with a valid cdr_arrangement_id to notify the Data Holder when consent is revoked by the consumer via the Data Recipient Software Product.

Data Holder's MUST use the Data Recipient Software Product's CDR Arrangement Revocation End Point with a valid cdr_arrangement_id to notify the Data Recipient Software Product when consent is revoked by the consumer via the Data Holder.

Change Proposed

The proposal is to update the affected section with the details below, to provide clarity on the Standards requirements relating to the updated wording of the Rules - 'the consent expires for any reason' and 'withdrawn or otherwise expires':

Revoking consent

Data Recipient Software Products MUST use the Data Holder's CDR Arrangement Revocation endpoint with a valid cdr_arrangement_id to notify the Data Holder when consent is withdrawn or otherwise expires, except for the following reasons:

• The withdrawal was initiated via the Data Holder,
• The consent expires at its natural expiry time, defined by the Data Recipient in the authorisation request and available in the token introspection endpoint,
• Invalidation of the consent due to a change in the Data Holder or Data Holder Brand status on the Register.

Data Holder's MUST use the Data Recipient Software Product's CDR Arrangement Revocation endpoint with a valid cdr_arrangement_id to notify the Data Recipient Software Product when an authorisation is withdrawn or otherwise expires, except for the following reasons:

• The withdrawal was initiated via the Data Recipient,
• The authorisation expires at its natural expiry time, defined by the Data Recipient in the authorisation request and available in the token introspection endpoint,
• Invalidation of the authorisation due to a change in the Data Recipient or Software Product status on the Register.

DSB Proposed Solution

The proposed solution can be found through the staging link provided in this comment.

[perlboy]

As long as this aligns with the reply provided here makes sense: ConsumerDataStandardsAustralia/standards#276 (comment)

[nils-work]

This change has been staged for review here -
ConsumerDataStandardsAustralia/standards-staging@08c804d#diff-61693f1655111f43af108588eafe96b9c1d3270e292d21e9f9bcfc31c6081c71

[nils-work]

This issue was raised in the agenda for the 20th March Maintenance Iteration call and there was no opposition to the change proposed, which has been staged.

[nils-work]

Standards version 1.30.0 was published on 24/04/2024 incorporating this change from MI18.