CDR-API-Stream
commented
3 years ago To improve readability and ensure the data standards only include statements related to future dated obligations and not legacy statements of obligation, the following changes are proposed. All historical reference to future dated obligations that have since taken affect would be retained in the archived releases of the data standards. Only the currently applicable statements of obligations would be retained in the latest release.
These changes will be staged in draft format for the community to review. The DSB is seeking any initial feedback prior to staging the changes.
Future Dated Obligations
In the future dated obligations section, it is proposed to remove the following references. These will remain in historical versions of the data standards and where applicable they will be represented in the Endpoint Versioning Schedule.
| Section | Description | Applicable Date |
|---|---|---|
| Get Product Detail V3 | Version 3 of this end point must be made available by affected data holders by the end of February 2021 | February 28th 2021 |
| Get Product Detail V2 | Data holders may obsolete version 2 of this end point from May 31st 2021. Data recipients must upgrade their implementations to use version 3 by this time | May 31st 2021 |
| Get Product Detail V2 | Version 2 of this end point must be made available by affected data holders by the end of July 2020 | July 31st 2020 |
| Get Product Detail V1 | Data holders may obsolete version 1 of this end point from August 29th 2020. Data recipients must upgrade their implementations to use version 2 by this time | August 29th 2020 |
| Get Products V3 | Version 3 of this end point must be made available by affected data holders by the end of February 2021 | February 28th 2021 |
| Get Products V2 | Data holders may obsolete version 2 of this end point from May 31st 2021. Data recipients must upgrade their implementations to use version 3 by this time | May 31st 2021 |
| Get Products V2 | Version 2 of this end point must be made available by affected data holders by the end of July 2020 | July 31st 2020 |
| Get Products V1 | Data holders may obsolete version 1 of this end point from August 29th 2020. Data recipients must upgrade their implementations to use version 2 by this time | August 29th 2020 |
| Concurrent Consent | The target state concurrent consent solution covers various components of the Information Security profile is being phased in with alignment to the November 2020 implementation milestone set by the ACCC. If this milestone moves then this obligation will also move. | November 1st 2020 |
| Token Revocation End Point | Data recipients may obsolete this end point from February 1st 2021. Data holders may obsolete consent revocation via this end point from February 1st 2021, however they must still support oAuth token revocation. Data recipients must upgrade their implementations to use the Data Holder CDR Arrangement Revocation End Point by this time. |
February 1st 2021 |
| Token Introspection claims | Whilst Data Holders must conform with the FAPI normative references, requiring the scope claim, the standards were clarified in v1.5.0 to clarify the minimum required set of claims to be supported by the Token Introspection end point. Data holders must support the scope claim not later than February 1st 2021 |
February 1st 2021 |
| Client Authentication for Data Recipients calling Data Holder | Client Authentication has been updated to align to upstream standards. From March 30th 2021, Data Holders must support multiple valid values for the audience claim for Data Recipient client authentication as outlined in that section. Data Recipients may continue to supply the URL of the endpoint being invoked, however according to upstream standards, it is recommended according to [RFC8414] that issuer identifier URL of the authorisation server should be used as the value of the audience. Until March 31st 2021, Data Recipients must continue to use the URL of the endpoint being invoked as the audience claim value. Data Holders must continue to accept and validate the URL of the endpoint being invoked. |
March 30th 2021 |
| Token Introspection Endpoint claims | Mandatory claims were updated in accordance with RFC7662 | November 1st 2020 |
Retrospectively obtaining a CDR Arrangement ID
It is proposed that the following statement is removed because they are covered by Data Holder obligations and relevant statements in the standards. Statements referring to retrospective population of the cdr_arrangement_id are no longer required now that all DHs have updated their implementations to support the CDR Arrangement ID and associated mechanisms:
For any existing consents, Data Holders must retrospectively generate a cdr_arrangement_id such that from November 2020, Data Recipients can obtain a valid cdr_arrangement_id for all active consents they hold.
It is proposed that the following statement will be incorporated into the "CDR Arrangement ID" section:
A Data Recipient can call either the Token or Token Introspection End Points at any point post-consent to obtain the CDR Arrangement ID in the response JSON as the claim cdr_arrangement_id.
Specifying an existing arrangement
It is proposed that the current statements are removed:
- Until November 2020 data holders are not required to take any action if cdr_arrangement_id is supplied but MUST NOT respond with an error.
- Until November 2020 data recipients MUST NOT implement scenarios that support concurrent consent. Only single, extant consent scenarios should be implemented until this date.
OpenID Provider Configuration End Point
It is proposed that the current statements retained but the clause regarding November 2020 is removed
Remove:
From November 2020, the Data Holder metadata MUST include:
Retain:
- cdr_arrangement_revocation_endpoint: The URL of the CDR Arrangement Revocation End Point for consent revocation
- pushed_authorization_request_endpoint: URL of the Pushed Authorisation End Point used to support [PAR].
CDR Arrangement Revocation End Point
It is proposed that the current statements are changed to simply state Data Holders and Data Recipients must implement the end point:
Change from:
From November 2020, Data Holders and Data Recipients MUST implement a CDR Arrangement Revocation End Point that can be used to revoke an existing sharing arrangement.
Change to:
Data Holders and Data Recipients MUST implement a CDR Arrangement Revocation End Point that can be used to revoke an existing sharing arrangement.
Pushed Authorisation End Point
It is proposed that the current statements are changed to simply state Data Holders must implement the end point:
Change from:
From November 2020, Data Holders MUST support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to [PAR].
Change to:
Data Holders MUST support Pushed Authorisation Requests (PAR) via the pushed authorisation end point according to [PAR].
Revoking consent
It is proposed that the current notes are removed:
NOTE: Data Recipients MUST continue to support this Token Revocation End Point until February 2021.
NOTE: Data Holders MUST continue to support consent revocation via the oAuth Token Revocation end point until February 2021.
Data Holders calling Data Recipients
It is proposed that the current statement is removed:
Data Recipients MUST continue to support their Token Revocation End Point until February 2021 and until they have updated their client registrations.
Get Products
It is proposed that the current notes is removed:
NOTE: This version must be implemented by February 2021
Get Product Detail
It is proposed that the current notes is removed:
NOTE: This version must be implemented by February 2021
Description
As the standards evolve, the list of future dated obligations grows. Over time the table becomes harder to navigate because it includes dates for obligations that have since occurred and are no longer in the future. The latest published version of the data standards future dated obligations table should only include obligations with a future date.
Area Affected
Future Dated Obligations and any dates mentioned within the standards that reference obligation dates that are in the past
Change Proposed
To ensure that future dated obligations are clear and understandable, remove any redundant future dated obligations where the dates have since passed. For example PRD v1 implementation and retirement dates. Previous versions of the standards will retain the older obligation dates for traceability.