ADR ability to remove DCR without clientId

[jimbasiq]

Description

We have multiple Software Products that are functioning well on the CDR framework with the exception of a single Data Holder due to a DCR failure.

If clientId is created while performing dynamic client registration with a dataholder for the first time, but something fails on either side (e.g. dataholder fails to return the clientId or data recipient fails to log/store the clientId), the data recipient gets locked and is unable to proceed without assistance from the data holder in question.

We have long running issues with data holders ranging from Tier 1 to smaller institutions. In each instance the Software Product has successfully registered with all other data holders.

Area Affected

The first issue is that subsequent dynamic client registration attempts will get rejected by the data holder, but the existing registration APIs available (see screenshot below) all rely on having clientId.

Secondly, in Consumer Data Standard (CDS), Client Registration Management, the authorisation server support for a Delete API is marked as optional. This means a Data Holder can choose to not implement the Delete API, this area has often not been thought about and some data holders do not have even a manual process for deleting a DCR, we have had an ongoing issue with a Tier one dataholder for more than 9 months.

Change Proposed

Two changes are proposed:

1. Delete API is marked as mandatory.
2. Have a mandatory data holder API where the existing DCR could be deleted without needing the clientId as a parameter on the request.

[markskript]

@jimbasiq we have also hit the issue a couple of times and have been stuck while waiting for the ADH to work out how to manually "delete" our client so we can re-attempt the DCR process.

We support change 1 of the proposal above.

For change 2, rather than having a "delete all DCR's" endpoint could we perhaps introduce a plain GET /register/ endpoint that lists the current DCR's from the ADH's perspective? We could then obtain the client ID from there and either manually configure it at the ADR end, or then use the existing DELETE endpoint to delete it.

[jimbasiq]

@jimbasiq we have also hit the issue a couple of times and have been stuck while waiting for the ADH to work out how to manually "delete" our client so we can re-attempt the DCR process.

We support change 1 of the proposal above.

For change 2, rather than having a "delete all DCR's" endpoint could we perhaps introduce a plain GET /register/ endpoint that lists the current DCR's from the ADH's perspective? We could then obtain the client ID from there and either manually configure it at the ADR end, or then use the existing DELETE endpoint to delete it.

Hi @markskript , thanks for the vote for 1. For 2, some of our DCRs have resulted in no client ID being generated on the data holder side.

[perlboy]

Firstly, if a holder is:

• failing to return a client id and blocking a reattempt to DCR it is non-compliant
• losing a registration it is non-compliant in multiple ways not least of which their obligation to the Consumer themselves
• not responding to technical assistance requests it is non-compliant

All of the scenarios described, especially if it's a combination of them, is grounds for enforcement action in my opinion, so certainly encourage incidents to be opened. It's unfortunate but I'm aware of at least one holder solution provider where recipient registration wipeout during upgrade is common place.

From my perspective any "solution" to this problem is just working around broken holders.

[NationalAustraliaBank]

Following is NAB’s perspective on the changes proposed:

1. Delete API is marked as mandatory. NAB is supportive on marking this API to be mandatory, along with an effective DCR Search solution (to get the clientId for Delete API) is defined, as proposed in below #2.
2. Have a mandatory data holder API where the existing DCR could be deleted without needing the clientId as a parameter on the request. NAB suggests keeping the existing DCR Delete API (clientId required), with below options to get clientId • Option 1: DH perform manual processes to search/generate the clientId and provide to the ADR’s on request • Option 2: DH implement mandatory DCR Search API (e.g. based on software_id) with proper authentication method defined (e.g. if SSA is not available. Need further discussion).

[perlboy]

I seriously question the value being derived of building something off-spec for this problem space. If Data Recipients are encountering the need to do DCR Delete on a regular basis then the Holder(s) are very likely to be non-compliant.

DCR Delete should only be required once in a blue moon (ie. during onboarding) and is the nuclear option when it comes to Arrangements. If DCR Delete's can be executed and leave arrangements in place that seems non-compliant too. We are aware of certain software providers which blow-up client registrations every upgrade. This is non-compliant, regardless if there is a recovery mechanism. @ACCC-CDR are you listening?

I don't think the ecosystem should be working around bad holders and those that are good holders would prefer to focus on something which adds Consumer value not providing an escape hatch for something that should rarely be used. By way of evidence, we service >15 Data Holders now, we have observed fewer than 5 DCR DELETE's in total in 3 years. Sure, mandate the DELETE endpoint if you like but going beyond that seems too far for the benefit.

[ACCC-CDR]

Thank you to all stakeholders who have provided their input on this important issue.

We have reviewed incidents raised on the Service Management Portal, and other channels. We are aware of a limited number of incidents in which data holders have, incorrectly, not provided a ClientID during DCR, and this has resulted in friction registering a relevant software product. Data holders must take their obligations seriously and, take steps to comply with the relevant obligations for every instance of DCR, including by ensuring the stability of its CDR platform. Failing to provide a ClientID is non-compliant with the Rules and Standards. Where instances of this conduct are identified the ACCC will consider them in line with the Joint Compliance and Enforcement Policy.

A key factor in considering the impact of non-compliance, are the measures data holders take to reduce the impact. If a data holder fails to provide a ClientID, a data recipient can seek the ClientID manually via the Service Management Portal. The effectiveness of this measure relies on a timely response from the data holders. We are aware that on some occasions data holders have not been timely in manually providing the ID, exacerbating the inconvenience for data recipients. As such, we encourage data holders to appropriately prepare for the scenario of a ClientID not being provided during DCR, for example, by having systems in place to log DCR requests and access ClientIDs for manual provision. The ACCC has been addressing the broader issue of slow data holder response times through a number of measures, including by introducing the Service Management Portal Service Level Objectives. The ACCC will also develop guidance to assist in these scenarios.

We note that in some cases reported in the Service Management Portal where a lost ClientID triggered the incident, other issues further increased the length of the delay completing DCR, and these other deficiencies in the data holder’s implementation would not be addressed by the proposed change.

Given the small number of occurrences reported to date in the Service Management Portal, and recent changes made to improve Service Management Portal processes our view is that no standards change is required to address the identified circumstances. The ACCC will continue to monitor instances of this conduct and will consider non-compliance in line with our compliance and enforcement policy. We encourage data recipients to promptly raise tickets via the Service Management Portal, to contact accc-cdr@accc.gov.au if a timely response is not received and to provide us with any additional intelligence about this issue. The ACCC considers the timeliness of responses to incidents, steps taken to address issues, and further measures implemented to prevent them from reoccurring when considering any response to non-compliance.

In relation to system changes impacting existing registrations, we would like to remind participants that we expect system changes not to impact existing data sharing arrangements, or to require new data sharing arrangements to be created. Breaches of the CDR framework, including early or improper termination of consent, are considered for further compliance or enforcement action. We encourage participants to report these instances in the Service Management Portal, or via accc-cdr@accc.gov.au

[jimbasiq]

Post further discussion in MI 15 on 31/05/2023 I have agreed that the primary requirement here is:

Delete API is marked as Required.

This will ensure a Data Holder has at least thought about how to process a Delete request.

A DP to this effect is expected.

[nils-work]

DSB Item - Consider process to recover from failed DCR #129 has been raised as a Future-Plan Decision Proposal placeholder to be addressed outside the Maintenance cycle.