Merge pull request #385 from ConsumerDataStandardsAustralia/maintenan…

…ce/631

Updates to 'Revoking consent' Standards

slate/source/includes/releasenotes/releasenotes.1.30.0.html.md

@@ -22,6 +22,7 @@ This release addresses the following minor defects raised on [Standards Staging]
 
 This release addresses the following change requests raised on [Standards Maintenance](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues):
 
+- [Standards Maintenance #631 - Updates to 'Revoking consent' Standards](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/631)
 - [Standards Maintenance #632 - Concurrent consent support and cdr_arrangement_id](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/632)
 - [Standards Maintenance #543 - refresh_token_expires_at and sharing_expires_at claims listed as MUST be supported](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/543)
 
@@ -59,6 +60,7 @@ This release addresses the following Decision Proposals published on [Standards]
 ## Information Security Profile
 |Change|Description|Link|
 |------|-----------|----|
+| Updates to 'Revoking consent' Standards | [**Standards Maintenance #631**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/631): Updates to 'Revoking consent' requirements to align to rules | [Security Endpoints](../../#security-endpoints)
 | Removed outdated statements | [**Standards Maintenance #632**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/632): Removed two outdated statements relating to the introduction of concurrent consent and retrospectively generating a cdr_arrangement_id. | [Identifiers and Subject Types](../../#identifiers-and-subject-types)
 | Removed outdated statements | [**Standards Maintenance #543**](https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/543): Removed outdated statements related to the `refresh_token_expires_at` and `sharing_expires_at` claims | [Scopes and Claims](../../#scopes-and-claims)<br>[Request Object](../../#request-object)
 

slate/source/includes/security/endpoints/_cdr_arrangement_revocation.md

@@ -134,9 +134,20 @@ Response Code | Situation | Description
 204 No Content | Success | The sharing arrangement has been revoked successfully
 422 Unprocessable Entity | Invalid Arrangement ID | The client submitted an invalid arrangement identifier or the identifier could not be found. The server MUST respond with [Invalid Consent Arrangement](#error-422-authorisation-invalid-arrangement).
 
+```diff
+Updates to 'Revoking consent' requirements to align to rules
+```
 
 **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 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:
 
-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.
+- 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.