Data Recipient unavailability back-off pattern

Question

As per ACCC’s guideline on Data Recipient unavailability, data holders should follow either a long term back-off pattern or a short term back-off pattern if the ADR is not available. For the first two retries, wait time in the long-term scenario are 200 milliseconds and 400 milliseconds. These initial retry wait times may not be relevant from a real world perspective as the gap between consecutive retries is in milliseconds. Also, 7 days duration (as per long term pattern) is too long and 10 minutes (as per short term pattern) is too short for a live application recovery point of view.

Considering these above-mentioned points and to provide a better customer experience, can the retry mechanism (in the case that the ADR is unavailable) be implemented as a combination of both short-term and long-term back-off patterns?

For example, the data holder could start with a short-term pattern (once in every minute for 10 minute or until recovery) followed by an exponential pattern as below:

Number of retries	Wait time in minutes
1	20
2	40
3	80
4	160

The intent is that the above pattern would continue for three days.

Please let us know your feedback on this proposed approach.

Answer

The back-off patterns currently defined help data holders meet the intent of the rules but it should be treated as a guideline and there is potential opportunity to implement alternate solutions. Participants will be expected to implement robust solutions which cater for temporary outages and recover in a graceful manner using “reasonable effort”.

A more detailed write up is provided in the comment section of GitHub issue #367 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/367:

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:

(a) whether 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.