Specify how participants can maintain synchronisation of consents after outages

[CDR-Register-Stream]

Description

When a withdrawal of authorisation is executed on the DH side, the DH is expected to notify the ADR by calling their appropriate revocation endpoint. If there is an outage on the ADR side, Data Holders are expected to retry calling using specified back-off patterns

Documentation improvements in the Register Design have been raised in issue 156

There would be benefit for further documentation to be provided to specify how DHs and ADRs should handle resynchronisation after an outage and through this work, opportunities for improvement to the standards identified

Area Affected

• Requirements for the Data Holder handling ADR outages should be revisited
• CDS error codes, revocation, introspection and token endpoints usage in this usecase should be specified and any potential improvements discussed

Change Proposed

Expectations and best practices for DRs and DHs to handle consent synchronisation issues should be documented and any improvements to the CDS identified and scheduled

[CDR-API-Stream]

Thanks @CDR-Register-Stream,

The DSB doesn’t consider the need for DHs to implement an exhaustive retry mechanism to be necessary or practical when the ADR is unavailable. The responsibility for availability and timeliness of the ADR solution is the responsibility of the ADR. Further to this, the DH doesn’t have visibility of ADR maintenance windows and outages.

Whilst the DH is responsible for communicating withdrawal of consumer consent when the consumer actions this through the DH dashboard, it is considered to be within the bounds of “reasonable effort”. The DSB leaves it to the discretion of DHs to determine reasonable effort based on their considerations and compliance obligations. Attempting to communicate the consent withdrawal via the CDR Arrangement Revocation endpoint by waiting a few seconds upon first failure would be suitable.

It is worth noting that upon restoration of service, it is expected that an ADR would validate all active consents to determine whether (a) they have expired, and if still current (b) whether they have been withdrawn by calling the DH token or token introspection endpoint. If consent is no longer valid, the request will return an error response communicating to the ADR’s software product that the refresh token is no longer valid. The ADR would update the consent status and ADR consumer dashboard accordingly.

[CDR-API-Stream]

The outcome of this issue has been decided by the Data Standards Chair that no change to standards will be made.

This issue will be closed accordingly.