Description

Issue #488 set the following requirement for data holders:

Data Holder Brands MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.

This change was recommended with an obligation date aligned with the Energy release timeframe of 15th November 2022.

Feedback from the ACCC requests that this obligation date moves to 15th September 2022, to ensure Data Holders are responding correctly to data requests prior to the implementation of the Energy Sector.

This change request has been raised to discuss this request.

Area Affected

Future Dated Obligation for issue #488

Change Proposed

Quote from ACCC's feedback on issue #488

ACCC strongly supports the proposed change outlined above and requests an earlier obligation date to support the introduction of Energy. ACCC proposes 15th September 2022 as the future dated obligation, to ensure Data Holders are responding correctly to data requests prior to the implementation of the Energy Sector

Firstly, within https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/488 there is a reference to a ZenDesk article. ZenDesk is not errata but it's worth noting that all this article does is clarify behaviour for unsupported scopes not the behaviour for unknown scopes. That is to say a Holder may not support certain scopes but may be validating what is supplied against what is known in the CDR - there's a few very good reasons, particularly in multi ecosystem deployments, for this. Given the date of the article I suspect the author wasn't assessing the multi-sector implication but rather the phasing component of Banking.

Specifically on this issue, this was indirectly highlighted March 2 and directly highlighted in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/484 note (2) on March 6:

Update (PUT) operations are to be used for one of two scenarios: The documented scenarios do not handle the possibility of unknown scopes being introduced into the SSA and as such, as the scenarios are explicitly defined, many Holders currently default to rejecting SSAs containing malformed scopes.

Nearly 2 months has passed since it was brought to the attention of Australian government representatives and now the request is shrink the FDO timeline, by 2 months, to fit the governments timeline. The irony here is that the government, particularly on the Register side, seems resistant to committing to basically any FDO for its own deliverables which smacks of hypocrisy.

In the interim there has also been potential solutions proposed for Register changes (such as offering filtered scopes per industry and avoiding the collapsing of paths to facilitate this use case among a few others). Sometimes they have been rejected for reasonable grounds but other times the key "sell" has been implementation complexity in the Register (who, for the record represents 1 of 90+ implementing parties in the ecosystem - that's 1.1% for those who enjoy vanity metrics).

Specifically in the ecosystem, I can confirm that at least 20 implementations (that's 22.2%) will reject unknown scopes at this stage and many are still grappling with Joint Account and Notifications (despite the extension) so backlogs are full. Ironically those implementations aren't Biza.io HaaS solutions (we already manage energy scopes and we are pretty close to releasing SSA updates on our test register to allow for testing) but are implementations used by customers we have completed Conformance testing on.

Regardless, this seems like a problem of the governments creation and on this basis alone why should industry consider a request for a reduction in the informally agreed cadence? The risk seems to be confined to one of political egg on face versus any existential ecosystem one so I don't really see the reasoning.

@perlboy, thanks for your input. The data points you have contributed help quantify this risk.

I'd like this discussion to focus on the cost-benefit to determine the reasonableness of this change. The cost of change to data holders is not well understood but the timeframe for change is very limited This risk is acknowledged and an operational rather than technical control is being proposed by the ACCC. This position is based on the lack of ACCC support for a technical control in #486.

Based on discussions in MI 11, In order to consider this change, further clarity is required to understand how this is going to work operationally. The following highlights points raised during this discussion

Moving the FDO will require data holders to go live earlier than the energy timeframe. This is expected to only impact banking data holders.
The intent is to provide the ACCC with the opportunity to see registrations exercised in production, prior to energy go-live, validating that data holders are compliant with the Standards.
The Register will need to add the additional energy authorisation scopes to the GetSSA response prior or by the 15th September 2022.
In order to minimise impact to the energy go-live, sufficient registration activity will need to occur early in the two month window to highlight which data holders are impacted. These data holders would then need sufficient time to rectify these issues prior to energy go-live.
To test the update registration endpoints, current data recipient software products will need to update their registrations early in this timeframe. What are their motivations to do this? Are there friendlies who are able to provide sufficient coverage?
To test the create registration endpoints, new data recipient software products will need to enter the CDR. Is there a pipeline of software products ready to go-live near the 15th September? Will these go-lives be coordinated to get sufficient coverage early in this window? Is this data which can be shared or treated as confidential?
Are there other operational mechanisms to help mitigate this risk? (Surveys, attestations, additional QA activities)
Is there an opportunity to get additional data to determine which data holders are able to meet this obligation? All of the above may be redundant if the number of data holders impacted at energy go-live is insignificant

In addition to understanding how this will work, we would be keen to hear from the community to understand the cost of change from moving this date.

Additional to the above, the DSB's default position will be to adopt the change of the FDO to the 15th of September 2022.

Additional feedback, particularly from data holders, will be required to help describe the impact of this change and the appropriateness of this change of date.

@perlboy, thanks for your input. The data points you have contributed help quantify this risk. I'd like this discussion to focus on the cost-benefit to determine the reasonableness of this change.

Happy to focus on this but it can't be done in isolation from the ACCC. Cost-benefit is a two way street.

The cost of change to data holders is not well understood but the timeframe for change is very limited This risk is acknowledged and an operational rather than technical control is being proposed by the ACCC.

Can the DSB make up its mind as to whether it is participating in operational matters or not? As per the closure of #453:

Operational considerations on how participants are informed of missing or invalid statuses are left for the ACCC to drive and are not part of the standards maintenance process.

Now the proposed DSB solution for this problem is an operational control?

This position is based on the lack of ACCC support for a technical control in #486.

And yet the ACCC proposed no alternative. What I fundamentally don't understand is why there's a desire to talk about cost-benefit but that seems to be to the exclusion of government bodies. "Dog fooding" seems like an appropriate term to use.

Anyways, I've proposed a method that might be a "quick fix" on this problem here and will answer the rest of this in that context: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/486#issuecomment-1153058157

Based on discussions in MI 11, In order to consider this change, further clarity is required to understand how this is going to work operationally. The following highlights points raised during this discussion

Moving the FDO will require data holders to go live earlier than the energy timeframe. This is expected to only impact banking data holders.

Moving an FDO sets a precedent - that a government body can fail to effectively design a technical solution and then change the schedules of every participant as a result.

The intent is to provide the ACCC with the opportunity to see registrations exercised in production, prior to energy go-live, validating that data holders are compliant with the Standards.

ACCC can't see them because the ACCC isn't a Data Recipient (although it probably should be but it's too busy writing sandboxes) so it will need to rely on Data Recipients to do it.

The issue here is what happens after a registration doesn't work.

The Data Recipient opens an incident on the CDR Portal
The Data Holder says "You moved the FDO 3 months and it isn't fixed yet"
ACCC sabre rattles about how it needs a resolution time from the Holder for a problem the government created and it refused to alter an implementation for
The Data Recipient still can't perform a registration or worse, can't perform an update which matters because they may not care about the energy scopes but DO want to update their redirect uris

The Register will need to add the additional energy authorisation scopes to the GetSSA response prior or by the 15th September 2022.

Well right now the FDO is November and asking for a delivery schedule has taken months with no response.

Anyways, the Register can implement the additional scopes in V3 of the SSA as long as it provides a mechanism to retrieve V2 so that way Data Recipients can revert in that direction (and that change isn't too crazy) and avoid (4) from above. Alternatively if there's some reason why V2 will no longer work the ACCC could introduce the scopes in a V4 of the SSA and the Standards could uplift that so that V3 didn't have energy scopes and V4 did.

In order to minimise impact to the energy go-live, sufficient registration activity will need to occur early in the two month window to highlight which data holders are impacted. These data holders would then need sufficient time to rectify these issues prior to energy go-live.

I don't see how this will work. If a Data Recipient wishes to update their registration it isn't just for energy scopes but may well be for redirect uris. This type of approach means a Data Recipient may be waiting months to update an errant redirect uri - ie. they could actually be down during this time with those Holders.

To test the update registration endpoints, current data recipient software products will need to update their registrations early in this timeframe. What are their motivations to do this? Are there friendlies who are able to provide sufficient coverage?

🤷 Maybe, maybe not, the government has done a pretty bang up job of motivating participants to help them out.

To test the create registration endpoints, new data recipient software products will need to enter the CDR. Is there a pipeline of software products ready to go-live near the 15th September? Will these go-lives be coordinated to get sufficient coverage early in this window? Is this data which can be shared or treated as confidential?

🤷 I guess the new ADRs will have to pass some CTS or something too but lets not talk about that.

Are there other operational mechanisms to help mitigate this risk? (Surveys, attestations, additional QA activities)

The ACCC could use its signing authority to experiment with its own Data Recipient with the new scopes ahead of Production release but I guess that's something it'd prefer to teflon onto all the participants.

Is there an opportunity to get additional data to determine which data holders are able to meet this obligation? All of the above may be redundant if the number of data holders impacted at energy go-live is insignificant

That depends, when will the ACCC introduce the new SSA with the new scopes. Requesting the ACCCs delivery schedule was actually rooted in some common sense of trying to forecast potential issues for Holders rather than out of some morbid curiosity.

In addition to understanding how this will work, we would be keen to hear from the community to understand the cost of change from moving this date.

This is about precedent. Every precedent the government sets that moves a timeline forward results in project managers leaving larger holes in their delivery schedules. Those holes when not filled result in missed opportunities for innovation or delays to other FDOs down the line.

The original pitch from the government was that energy would be introduced and not require banking holders to change, that type of message results in headcount reductions on implementing teams.

One additional issue identified is the proposed obligation date. 15th September 2022 does not align to any of the obligation milestones defined in the obligation dates schedule

The closest milestones are listed below:

Obligation Milestone	Milestone Date	# Obligations Assigned
Y22 #3	31/08/2022	2
Y22 #4	15/11/2022	0

If Y22 4 15/11/2022 were selected, this would represent no change in FDO If Y22 3 31/08/2022 were selected, this would reduce the delivery timeframe by a further 2 weeks from 15th September 2022

As per our original request in issue #488, the ACCC supports the move of the future dated obligation (FDO) to the 15th of September 2022 or the 31st of August 2022. The move of the FDO will assist the ACCC in ensuring Data Holders are responding correctly to data requests prior to the implementation of the Energy Sector.

The ACCC encourages any Data Holders that does not believe it will be able to meet the FDO to engage with the ACCC via the CDR Service Management Portal or the CDR Technical Operations Mailbox.

Several questions still need to be clarified to understand ACCC's proposal.

Will GetSSA with energy scopes be released by the ACCC in time for this obligation? Based on Issue #486, GetSSA V3 would be the only SSA version to contain energy scopes.
Is the ACCC expecting registrations to be created/updated in production, using SSAs with energy scopes, prior to the go-live of Energy on the 15th November 2022?
Will there be any other technical mechanisms to validate compliance for this obligation date (e.g. CTS)?
What is the latest that the ACCC would like this obligation given that the 15th of September is still being proposed? The obligation dates schedule was defined in MI 9 to provide implementers greater certainty on when delivery would be required and there may be impact by not aligning to these dates

Concerning the obligation date: a workaround for this issue has been proposed (see issue #486). An unfortunate aspect of this workaround is that it puts the onus on ADRs to handle non-compliant data holder behaviour. The proper outcome is that this behaviour be remediated by the relevant data holders before the Energy rollout enlivens this issue. The ACCC contends that an obligation date of 15 Sep is the latest date that is consistent with this outcome.

Thanks @ACCC-CDR and @perlboy for your contributions.

To summarise, through issue 507, the @ACCC-CDR raised a request to move the obligation date from 15th November 2022 to the 15th of September 2022 to ensure any non-compliant behaviour be remediated by the relevant data holders before the Energy rollout.

Issue 486 has been recommended in Maintenance Iteration 11 to ensure data recipients have a technical work-around if they encounter non-compliant data holders in production. This provides flexibility to the ecosystem in the case where non-compliance results in the inability for data recipients to request consumer data from non-compliant data holders.

Analysis was provided by the DSB and the community to help to understand the motivations for moving this obligation date and elicit what operational plan will be used to remediate non-compliant data holders. No response to this analysis has been provided by the ACCC so there is little visibility how non-compliance will be identified and handled.

Feedback on this issue included @perlboy indicating lack of support for the movement of the obligation date, however, no additional feedback has been provided, especially from data holders and data recipients currently impacted.

However, as this change is operational in nature and does not materially impact the Standards (other than obligation dates), the DSB has decided to support this change.

The Obligation Dates Schedule does not include the 15th of September 2022, therefore the date 31st August 2022 was selected, as this is the last meaningful obligation date prior to the release of Energy.

Proposal

The DSB proposes to move the obligation date from 15th November 2022 to 31st of August 2022, for the following requirement


Registration Validation	Data Holders MUST ignore unsupported authorisation scopes presented in the SSA for the creation and update of client registrations.

Everyone actively involved in the consultation process wants the Consumer Data Right to succeed. This success is dependent on many different factors but a major one of those is the technical delivery by an army of specialists at holders, recipients and within government. Despite the fact the CDR is a government initiative the reality is that the investment of time and energy is disproportionality weighted towards private enterprise. This includes participation, for essentially zero economic benefit, in the Maintenance Iteration process. Additionally the Maintenance Iteration process has been promoted as a means for participants to get actively involved in the development of the Standards.

While I could comment on the technical outcome here I think there's greater value instead in commenting on how this issue has created a precedent that is quite damaging to the continued participation of the technical folk the government could and has derived significant benefit from. It seems particularly poignant because on this issue I've personally received multiple contacts from highly skilled specialists in this field demoralised by how representatives of government seem to ignore contributions made directly or indirectly to the process.

Consultation on the FDO for this obligation was a spinoff from Maintenance Issue https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/488 which identified that "further discussion is required to consider having an FDO less the 6 months out". As part of MI11 I raised that a significant subset of Holders would demonstrate the unwanted behaviour (not ignoring scopes). Somewhat ironically I noted this was not something that impacted Biza.io as we have always ignored unknown scopes. Essentially, my concern was one based in ecosystem impact not commercial benefit. As discussion progressed a workaround was found that Data Recipients could use (specifying a previous version) and for which no Recipient opposed and private feedback received indicated they were already supporting. I also noted that the use of a Future Dated Obligation by the ACCC as a signalling mechanism by the Regulator was a blunt tool that wasn't conducive to a healthy relationship between implementers and the regulator.

In the last meeting for Maintenance Iteration 11, held June 29, the following were taken as actions:

ACCC requesting input from industry on issue #507.
ACCC to post a clarification on the need for the FDO for issue #507 to be brought forward if the purpose is not to enable enforcement action and to confirm dates the change will take effect.

On (1), while I can't speak to who the ACCC contacted on this issue I can at least anecdotally confirm that the Regulator did not raise this issue with any of our customers for where Biza.io is delivering CDR (ie. Not Impacted) and for where Biza.io is involved in the verification of CDR delivery (ie. Impacted parties) by third parties. By our measure this translates to a >50% count of the total ecosystem by Holder count.

On (2), the ACCC doesn't appear to have articulated this purpose in this thread. Further the ACCC rejected the proposed workaround apparently based purely on its interpretation of the "onus" on Data Recipients. There was no further evidence provided to support this conclusion.

From July 7 to July 25, this issue contained only government representatives of the ACCC and the DSB interacting in it. Maintenance Iteration 11 had no further meetings and there was no further discussion. As of last night the the future dated obligation was published (and formally defined in the Standards for the first time) as August 31st 2022. In addition, Maintenance Iteration 12 kicked off on July 20, which had a retrospective on Maintenance Iteration 11 but for which it would have been impossible to provide this feedback because the DSB didn't post the revised proposal until July 25.

The outcome of this sequence of events is disappointing primarily because what it has established is that the government has effectively overridden the contribution of private enterprise for what appears to be faux reasons, which hadn't been independently verified, after the consultation window had been closed. If this issue had been one from private enterprise it probably would have been progressed into MI12. Further it has established that effectively the Regulator seems to be able to beat the DSB (and the Chair) into submission.

Such behaviour by the government does very little to encourage well meaning technical folk, for which the government has derived so much value from, to continue to participate in this process. For those of us in private sector who have ridden through the public sector churn we've observed numerous technical staff become dejected, burnt out, hostile and/or melancholy (among other feelings) at how the government has "used", "ignored", "misrepresented", "pressured" or "been unreasonable".

As I stated in the beginning, everyone wants the Consumer Data Right to succeed but beyond this I feel a personal obligation to highlight to everybody, particularly the government participants, that this success is not something that can be produced by any single party, everybody has to be encouraged to come along for the ride. The process followed in this issue seems to be symptomatic of an underlying problem that is holding the CDR back from reaching the successful outcome it has the potential to.

Thank you for your feedback @perlboy. We can assure you that it will be seriously factored in if a situation like this, where an FDO is requested to be brought forward, is proposed. As stated previously the DSB have supported this change primarily because it is the purview of the regulator as to how and when compliance obligations are to be enforced and the standards themselves are not materially impacted.

Considering how near the new FDO now is the ACCC have provided guidance for any participant that may not be able to meet the new FDO date to make contact with them to discuss their situation.

Specifically the ACCC have asked us to post that:

The ACCC encourages any Data Holders that does not believe it will be able to meet the FDO to engage with the ACCC via the CDR Service Management Portal or the CDR Technical Operations Mailbox.

I'm really trying to be constructive here but this type of response continues to display the apathy "the government" (that's DSB, ACCC and anyone else funded by the tax payer) seems to have to well meaning technical implementers trying to help the government achieve its policy objective.

As a side note, FDOs are published in the Standards and the Standards are set by the Chair. It is unclear how the Regulator has any authority over these.

I continue to be disappointed that government representatives are unwilling to even acknowledge the personal impact that these type of decisions are having on individuals involved in the CDR.

ConsumerDataStandardsAustralia / standards-maintenance

FDO for data holders ignoring unsupported authorisation scopes to be set earlier than energy release date #507

Description

Area Affected

Change Proposed

Proposal