Define deprecation date for PRD v2

[CDR-API-Stream]

Description

PRD v3 APIs are required by February 28th 2021. A suitable retirement date for v2 APIs allows DHs to reduce the maintenance of the deprecated v2 versions of the endpoints whilst considering a reasonable time to allow ADRs to transition to using v3 of the affected endpoints.

Area Affected

Get Products v2 API
Get Product Detail v2 API

Change Proposed

Define a deprecation date for v2 APIs so DHs can retire the older v2 APIs. ADRs would rely solely on v3 from the agreed date.

[adrcdr]

v2 API cannot be deprecated until all holder are at v3, there is long list of exemptions for obligation until at least July 2021
https://www.accc.gov.au/public-registers/consumer-data-right-exemptions-register

[CDR-API-Stream]

Hi @adrcdr the standards aren't intended to represent a list of all exemptions granted to individual participants as these are subject to change and considerations are specific to each exemption. If the standards tried to deal with all exemptions, it would unfairly impact participants meeting their obligations on-time or ahead of time. The purpose of the deprecation guidance is so that recipients have some certainty as to the APIs that they need to support and there is certainty for phasing in transition.

DHs that have sought an extension to their obligations would be expected to be compliant with the version of the APIs that are defined in the standards at the time they go live and may be subject to any negotiation with the ACCC when the exemption or subsequent extensions are granted.

[CDR-API-Stream]

This issue was discussed during the maintenance iteration call. Refer to meeting agenda and notes: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/DSB-Maintenance-Iteration-6:-Agenda-&-Meeting-Notes-(17th-March-2021)

A 3 month deprecation phase is proposed. This would define a retirement date for PRD v2 APIs of May 31st 2021.

DHs would be able to retire v2 endpoints from this date forwards. It would not force DHs to retire the endpoints on this date, but represent the earliest date DHs may retire these endpoints.

Feedback is welcomed.

[adrcdr]

Many existing holder broken support for x-min-v and x-v version select. v2 retirement mean adr force to make many call and many fail for v3 while must keep do v2 call for holder with exemption. Retirement only happen when holder fix version selection or error rate go up lots.

[CDR-API-Stream]

Hi @adrcdr, if holder implementations are incorrectly servicing the version headers, this is not specific to the phasing of PRD v2 endpoints and should be taken up with the ACCC's compliance and enforcement team. You may also reach out by to us directly by providing details of versioning issues here: https://cdr-support.zendesk.com/hc/en-us/requests/new.

Can you elaborate on what you mean by ADRs making many calls that fail for v3? Is this because you are seeing few with the v3 version implemented? This would be non-compliant and would need to be dealt with via C&E.

[adrcdr]

Data consumer make call for range of endpoint and holder reject with undefine error because spec specify no error. Data consumer ask for v2 only in meantime work. Ask data consumer to contact one government box because other government box remove working system make no sense. What happen to no wrong door.

[CDR-API-Stream]

The proposed changes for the deprecation date of PRD v2 has been staged here for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/tree/maintenance/368

[CDR-API-Stream]

The outcome of this issue has been approved by the Data Standards Chair for inclusion in v1.9.0. A change to the data standards was recommended.

This issue will be closed accordingly.