Get Metrics v4 & v5 authorisations property changed from optional to mandatory as part of Maintenance Issue 599 & v1.27.0

[MrWoo16]

Description

The CDS v1.27.0 published on 10 October 2023 includes a change that updates the Get Metrics v4 & v5 authorisations property from optional to mandatory. This change has been classed as a minor non-breaking change within Maintenance Issue 599.

However we have, and I'm sure other data holders will have done the same, based our new Get Metrics v4 response on the direction in CDS v1.25.0 that confirmed the new authorisations property was optional, with the assumption that the individual metrics under this property would be mandatory if the authorisations property was returned.

As the ACCC / CDS deadline to implement Get Metrics v4 is the 1 November 2023 we have taken the approach at this time to emit the authorisations property from the v4 response, as the collection of all the required authorisations, revocations and expiry metrics for population within the GET Metrics API response requires significant re-development and enhancements.

Again I'm sure we are not alone with this approach and development requirement with the assumption that a number of data holders will be facing the same non compliance issue as a result of this 'simple' wording change.

The section within Maintenance Issue 599 confirms:

"The authorisations property in Get Metrics v4 and v5 is marked as optional. This may have been intended to be mandatory as per most other top-level properties".

Area Affected

Get Metrics v4 and v5 authorisations property within v1.27.0 changed from optional to mandatory.

Change Proposed

Can you please advise whether the authorisations property was intended to be optional or mandatory as the original Decision 288 –Non-Functional Requirements Revision does not provide any clear direction on this.

Given this change to make the authorisations property mandatory is a breaking change requiring a longer development timeline can this property be changed back to optional?

Apologies if this has been covered elsewhere rather than CDS v1.25.0 and Decision 288 – Non-Functional Requirements Revision

[perlboy]

Some vendors have already shipped Get Metrics endpoints following the unreasonable timelines prescribed by the DSB and the ACCC. Any change to the Standards regarding these endpoints will not be applied by November 1 and any expectation is unreasonable.

[MrWoo16]

Can you please provide an update whether this issue has been reviewed or is being considered for review to determine whether the change of the Get Metrics v4 and v5 authorisations property from optional to mandatory as part of v1.27.0 was done in error?

It appears that this issue is NOT currently included for consideration as part Maintenance Iteration 17, and given the timeline for the implementation and support of the Get Metrics v4 endpoint is from 1st November 2023, confirmation if this change was planned and required is welcome.

[CDR-API-Stream]

Hi @MrWoo16

The comment you referred to on issue 599 was added during Maintenance Iteration 16 on 24 Aug., in recognition of an error identified after the release of Standards version 1.25.0, in which the updates to the Get Metrics endpoint were introduced.

That error was corrected in the release of version 1.27.0 on 10 Oct., as part of the outcome from the Maintenance Iteration. The change to make that field mandatory was not made in error.

Regarding the optionality of fields, the Standards also provide this statement:

Note that optional fields are not considered optionally implementable by a Data Holder.

[MrWoo16]

Thank you for your reply above.

Whilst this potential error was identified as part of Issue 599, the evidence statement below does not definitively identify and show that this was an actual error as part of v1.25.0:

The authorisations property in Get Metrics v4 and v5 is marked as optional. This may have been intended to be mandatory as per most other top-level properties.

The inclusion of "may" in the above quote appears to indicate that it could have been an error rather than pointing to the original and actual requirements showing that the new authorisation metrics were mandatory from 1 November 2023.

I've checked through the original Get Metrics v4 and v5 proposals and cannot find anything to direct that the new authorisations metrics was intended to be mandatory from 1 November 2023.

Given the potential scale of this change to make the required authorisation metrics available via the GET Metrics endpoints, I'm surprised that the wider data holder and CDR solution providers eco-system did not identify the potential challenges to complete this extension in the timeline between v1.25.0 being published on 8 July and Get Metrics v4 being implemented by 1 November 2023.

Whilst I fully acknowledge that "optional fields are not considered optionally implementable by a Data Holder" when that Data Holder holds that information, the pivot to be able to identify and collect all the required authorisations, revocations and expiry metrics for population within the GET Metrics API response requires significant re-development and enhancements.

Can you please confirm and/or link the original requirements that document that the new authorisations metrics were a mandatory requirement as part of the v4 and v5 implementations?

The above reference is required as, probably like a number of data holders and CDR solution providers, our current Get Metrics v4 response is not compliant with this change published in v1.27.0.

[CDR-API-Stream]

The DSB acknowledges feedback that the requirement of the authorisations property wasn't accurate at the time of publishing version 1.25.0. After the issue was identified, guidance was provided through the CDR Support Portal and the CDR Implementation Call, and a correction was made to the standards as soon as practicable.

For related issues on compliance, the ACCC and OAIC Compliance and Enforcement policy sets out the general approach to CDR compliance and enforcement and their strategic and risk based approach and may be consulted.

[MrWoo16]

Thanks for the further updates and feedback.

Apologies for laboring this point, however, given the significant impact of this small tweak that is a breaking change with a large development and change requirement I wish to ensure that I've identified the correct points this correction was identified as being needed and being called out.

With reference to the guidance being provided through the CDR Support Portal I assume you are referencing this article: Guidance on Get Metrics V3, V4 and V5.

I also assume that this correction was identified on 6 September based on Issue 599 and discussed as part of the DSB Maintenance 16 Session on 6 September. Based on this session minutes, it appears that this correction was discussed as part of Issue 599, which covered the minor documentation updates and other amendments with no objections being noted.

Whilst I did not attend the DSB Maintenance Iteration 16 call on 6 September, I'm surprised that no one identified and called out the significance of this correction and questioned whether it was actually a minor non-breaking change, and instead required greater discussion on the impact to data holders and CDR solution providers.

[DougFromPayPal]

The amount of work required to support this authorization object is significant. At the time this was prioritized, it was optional and how our V5 was coded and launched into production. This is not remotely a minor non-breaking change and will require a fairly large analysis to determine current capability and data availability, as well as the development effort to support.

[CDR-API-Stream]

Dear @MrWoo16 and @DougFromPayPal

In relation to guidance being provided on the CDR Support Portal and the CDR Implementation Call, the details may be found in the agenda, in the responses to ticket 2074 (24 August 2023) and 2087 (31 August 2023).

The comment on issue 599 was also posted on 24 August and discussed in the Maintenance Iteration call on 6 September, as part of the review of the holistic changes. The change to fix the incorrect requirement was staged on the same day and linked in this comment. There were no concerns raised in the Maintenance call or related to the staged change.

Decision Proposal 288 - Non-Functional Requirements Revision declared the intent of the field by stating "A new authorisations field will be added to Get Metrics". The consultation did not consider that it would be an optional field.

Although version 1.25.0 described the 'authorisations' field as optional, this was communicated as being an error once the DSB had become aware, which was approximately seven weeks after the version had been published (as stated above). As the change to the Standards was being treated as a correction only, it was resolved through the Maintenance Iteration process, resulting in version 1.27.0.

If there are concerns about compliance as a result of these or other matters, please refer to the ACCC and OAIC Compliance and Enforcement policy which sets out the general approach to CDR compliance and enforcement, and their strategic and risk based approach.