Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to 'Revoking consent' Standards #385

Merged
merged 2 commits into from
Apr 22, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand Down Expand Up @@ -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)

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.