DSB Maintenance Iteration 10: Agenda & Meeting Notes (13 April 2022)
Date and time: 13/04/2022, 2:00pm – 4:00pm AEDT
Location: WebEx
Dial-in details:
- https://treasuryau.webex.com/treasuryau/j.php?MTID=mf148de6a206fb95e1d25055ee9b7c90d
- Dial In Number: +61 2 9338 2221
- Dial In Access Code: 2653 293 7148
- Quick Dial: +61-2-9338-2221,,26532937148## Australia Toll
Chair: Ivan Hosgood, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 237
The Maintenance Iteration Calls are recorded for note taking purposes only. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material will be provided without the participant's consent. Participants may email [email protected] should they have any further questions or wish to have any material redacted from the record.
We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
"During the caretaker period, the business of government continues and ordinary matters of administration still need to be addressed."
Refer Section 2.4 of the Guidance on Caretaker Conventions.
The making and amending of the non-legislative Data Standard instruments are considered an ordinary matter of administration.
Maintenance Iteration 11 is scheduled to commence on 27 April 2022. A place holder invitation has been sent and will be updated in the coming days. Publication of Decision Proposal 237 and v1.17.0 of the Standards may occur after this date, depending on timing for a decision from the DSB Chair.
- Introductions
- Outstanding Actions
- Release plan
- Open Decision Proposals: key consultation dates
- Iteration 10 issues
- Any other business
Meeting notes
This week is the sixth and final call of the 10th maintenance iteration.
The purpose of the meeting is to close out the candidates consulted on in 10th maintenance iteration.
- Overview, purpose and intended outcomes of the meeting
- DSB to reach out to ADR contacts to assess priority of change for MI10 banking change requests #291 and #292.
- NAB to perform analysis on Issue #229 Service field in the Get Transaction Details API and advise on outcome in MI10 Meeting #2.
- Issue #439 DSB to propose solutions options to accommodate pricing models as an attribute of the charge instead of the contract.
- Issue #472 DSB to raise new issue to assess consistent representation of ENUM values for 'days' across sectors and within energy endpoints - Link to CR
- Issue #444 ACCC to publish a description of the new unauthenticated API on the issue and address industry requests.
- Issue #439 DSB to draft the proposal for review and if there is no further comment from participants the change will be recommended to the Chair.
- Issue #476 DSB to update option 2 with any feedback received and will recommend the change to the Chair.
- Issue #476 DSB to remove "additionalValue" attribute and apply condition to "additionalInfo" attribute to be mandatory if type is "VARIABLE".
- Issue #477 DSB will put forth the position, for comments from industry, that retailers must consume and publish AEMO outage and status at an FDO yet to be determined. If there are no objections the change will be recommended to the DSB Chair.
- Issue #478 DSB to update proposal to specify the scenarios raised in the original CR where existing error codes will be applicable.
- Issue #444 DSB to assess whether all consequences associated to the issue have been considered and discuss at the meeting on 13 April 2022.
- Issue #444 DSB to add commentary on the ticket to address the relationship between statuses and DP245.
- Issue #435 Biza/Participant to provide comments for further consideration
- Issue #464 DSB will work through the issue to determine opportunities for improvement to address MI9 Retrospective. IN PROGRESS
- Issue #435 DSB will follow up with the CDR Rules team and the OAIC regarding privacy considerations with sharing a second-party's details under the primary consumer's consent
- Issue #458 DSB to include examples to describe the transition to FAPI 1.0
- Issue #488 DSB to discuss internally what evidence can be presented to determine whether DHs will be non-compliant when scopes grow
- Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
- Issue #435 DSB to update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April.
- Issue 458 DSB will discuss the issue of potential documentation changes to accommodate upstream changes to JARM when FAPI moves from optional to mandatory offline and update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. Considerations will need to be made on whether the Discovery Configuration Endpoint and DCR documentation should be updated to defer to the upstream standards or explicitly document the fields required to enable JARM support.
- Issue #486 ACCC to provide feedback on the proposal and comment on the feasibility of FDO.
- 1.16.1 was released on the 22nd of March 2022.
- MI 10 change requests will be published in release 1.17.0
- Refer to the obligation dates agreed on in MI10 Meeting #3.
The following decision proposals are open for community feedback
| DP # | Closing date | DP |
|---|---|---|
| 229 | Placeholder | Decision Proposal 229 - CDR Participant Representation |
| 203 | No closing date | Normative Standards Review (2021) |
| 240 | No closing date | Decision Proposal 240 - ADR Metrics |
| 245 | TBD | Soon to be published: Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation |
All open change requests can be found here: Standards Maintenance Issues.
The standards maintenance backlog can be found here: Data Standards Maintenance
The following change requests are currently in the design stage for this iteration
| Issue # | Sector | Change Request | Decision | Change Status | Future Dated Obligation (FD) |
Affected Schema (if applicable) |
Affected Endpoint (if applicable) |
Recommendation |
|---|---|---|---|---|---|---|---|---|
| 448 | Energy | EnergyPlanDiscounts contains optional fields that should be conditional | Change Recommended | Non-breaking change | 01/10/2022 | EnergyPlanDiscounts | Adopt the change | |
| 449 | Energy | EnergyPlanSolarFeedInTariff days field should be mandatory | Change Recommended | Non-breaking change | 01/10/2022 | EnergyPlanSolarFeedInTariff | Adopt the change | |
| 457 | Energy | Energy - Get Service Point Detail register suffix should be optional | Change Recommended | Non-breaking change | 15/11/2022 | EnergyServicePointDetail | Adopt the change | |
| 423 | Energy | Review of demand charges in energy billing transactions | Change Recommended | Non-breaking change | 15/11/2022 | EnergyBillingTransaction | No change required as otherCharges already allows capturing network charges, which would include demand charges for C&I customers. | |
| 438 | Energy | Representing adjustment transactions within the Billing Payload for C&I customers | Change Recommended | Non-breaking change | 15/11/2022 | EnergyBillingOtherTransaction | Amend 'otherCharges' to include 'calculationFactors' and 'adjustments' as per this comment | |
| 439 | Energy | Review Pricing Model & Time Zone attributes within Account Detail Payload | Change Recommended | Non-breaking change | 15/11/2022 | Get Energy Account Detail | Include an optional ‘timeZone’ attribute within EnergyPlanTariffPeriod so charge specific time zones can be provided. If absent, contract level timezone would be assumed. | |
| 472 | Energy | Modify Energy Plans structure to allow Time of Use based Controlled Load rates | Change Recommended | Non-breaking change | 01/10/2022 | EnergyPlanControlledLoad | Amend 'controlledLoad' object to cater for time of use based rates as per this comment | |
| 476 | Energy | Modify Energy concessions structure to allow non-fixed (e.g. daily, monthly etc.) concessions | Change Recommended | Non-breaking change | 15/11/2022 | EnergyConcessionsResponse | Amend EnergyConcessionsResponse schema to allow representation of concessions that are calculated based on variable parameters with the changes specified in this comment | |
| 477 | Energy | Secondary Data Holder Planned Outages and Status | Change Recommended | Non-breaking change | TBD | The following changes are recommended: - AEMO to host publicly available 'Get Status' and 'Get Outages' endpoints for secondary data - Retailers must consume and publish AEMO outage and status information via their own 'Get Status' and 'Get Outages' endpoints |
||
| 478 | Energy | Energy Secondary Data Holder & Application Specific Errors | Change Recommended | Non-breaking change | 15/11/2022 | EnergyServicePointDetail | Make “meters” and “register” objects in EnergyServicePointDetail optional to cater for scenarios where meter or register information for a NMI is not available. No other changes are required. Summary of scenarios can be found here | |
| 453 | Register | Consider an upper bound on trusting entity statuses when they go missing | Change Recommended | Non-breaking change | N/A | Specify no upper-bound and no FDO | ||
| 465 | Register | Confirm Register API 2022 release dates | Change Recommended | Non-breaking change | 15/11/2022 | Change binding dates for new CDR Register API versions to the 15th of November 2022 | ||
| 498 | Register | New Register Authenticated APIs versions require multiple authorisation scopes | Change Recommended | Non-breaking change | Correct defect in the swagger so only the cdr-register:read scope is required for new versions of the CDR Register authenticated APIs |
|||
| 501 | Register | Register API x-v headers moving to mandatory impacts compatibility with older versions of these APIs | Change Recommended | Non-breaking change | N/A | Rollback x-v changes from mandatory to optional for new CDR Register API versions. Also explicitly call out that the default version of the response when x-v is not provided will be the minimum supported version |
||
| 452 | Register | Deprecation and retirement dates for CDR Register superseded endpoint versions needs to be defined | Change Recommended | Breaking Change | 07/04/2023 | N/A | CDR Register APIs | Deprecation and retirement dates for superceded CDR Register endpoints should follow conventions already established by the DSB. |
| 459 | Register | Sector Agnostic Register APIs | Not Supported | No change | N/A | N/A | N/A | Its DSB's position that insufficient benefit would be obtained from this change and future improvements to the Register APIs may be impacted by collapsing these URLs. DSB recommends that this change is not to be adopted |
| 444 | Register | Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API | Change Recommended | Non-breaking change | Introduce a new API dedicated to data holder brand public endpoint discovery | |||
| 488 | Register | Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes | Change Recommended | Breaking change | 15/11/2022 | N/A | Register Data Recipient oAuth Client, Update Data Recipient Registration | Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations. |
| 486 | Register | Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products | Continue consultation through next maintenance iteration / DP | N/A | N/A | N/A | N/A | This topic is complex and requires futher consultation time, or dedicated consultation through a DP |
| 443 | Register | SSA definition: Deprecation of revocation_uri | Change Recommended | Breaking Change | 15/11/2022 | N/A | Get Software Statement Assertion (SSA) | SSA Change management will conform to the conventions already laid out in the Consumer Data Standards. Revocation_uri will be removed from the SSA definition |
| 431 | Register | Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive | Deferred | N/A | N/A | N/A | N/A | This issue has been deferred from maintenance iteration 10 at the request of the ACCC |
| 405 | Infosec | Alternative mechanisms for OTP | Deferred | Carry over to Maintenance Iteration 11 - note this change is impacted by Caretaker mode and cannot be consulted on until the conclusion of caretaker mode | ||||
| 435 | Infosec | Nominated representative end user for non-individual consumers | Deferred | Carry over to Maintenance Iteration 11 - the discussion is still ongoing and no solution has yet been agreed | ||||
| 482 | Infosec | JWT signing non-normative examples use unsupported signing algorithm | Change Recommended | Non-breaking change | N/A | N/A | N/A | Non-normative example update |
| 458 | InfoSec | FAPI 1.0 Non Normative Examples | Deferred | Carry over to Maintenance Iteration 11 - the discussion is still ongoing and no solution has yet been agreed |
| Issue # | Sector/Domain | Change Request |
|---|---|---|
| 484 | Register | 1.13.0 Appears to have introduced new SSA error behaviours |
The following change requests had been proposed for this iteration however there isn't enough remaining capacity to accommodate them. They will be prioritised for Maintenance Iteration 11 provided there is community support and no further issues with a higher priority emerge.