DSB Maintenance Iteration 10: Agenda & Meeting Notes (16 March 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki
Date and time: 16/03/2022, 2:00pm – 4:00pm AEDT
NOTE: meeting duration has been extended to 2 hours to accommodate Information Security, Register, Banking and Energy.
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
Recording
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.
Acknowledgement of Country
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.
Agenda
- Introductions
- Outstanding Actions
- Release plan
- Obligation Dates
- Maintenance / Release Process Changes
- Open Decision Proposals: key consultation dates
- Iteration 10 issues
- Any other business
Meeting notes
Introductions
This week is the third call of the 10th maintenance iteration.
The purpose of the meeting is to collaborate on issues targeted in the 10th maintenance iteration.
- Overview, purpose and intended outcomes of the meeting
Outstanding Actions
- DSB will work through Issue #464 to determine opportunities for improvement to address MI9 Retrospective.
- 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.
- Obligation dates. DSB to revisit proposed date of 1 November 2022 date and align with Energy milestones
- DSB to investigate copyright permissions and IP issues associated with development of AEMO endpoints to ensure design of the APIs is publicly available
- Issue #438 A definition for Calculation Factor is required. Kingson EA to check and advise. DSB will then draft up structure to accommodate proposed changes for comment.
- Issue #439 DSB to propose solutions options to accommodate pricing models as an attribute of the charge instead of the contract.
- Issue #472 Kingson EA to comment on the issue providing rationale to include start and end dates.
- DSB to consider alignment of definition for BUSINESS DAYS and ENUM values for DAYS across sectors
- DSB to fix defect of missing ENUM in standards. Action has been completed refer to Issue #134 on Standards-Staging
- Issue #476 DSB to consider aligning methods to calculate energy concession rates with banking interest rates to standardise across sectors where possible.
- Issue #477 DSB to propose a third Option for AEMO to publish outages via an API that can be consumed by retailers to incorporate AEMO outages with their own. Action completed, refer to comment
- Issue #478 DSB has flagged #478 as potential candidate for this iteration and will add it to the Agenda for Meeting #3 in response to AEMO request as it is more critical than others currently in design.
- Issue #452 DSB to propose deprecation dates on each new Register API version
- Issue #452 DSB to model out scenarios for data holder behaviour when presented with unsupported authorisation scopes in the registration flows. This includes validating the assumption that Banking will not be impacted by the implementation of Energy.
- Issue #452 DSB to escalate the issue of testing coordination for energy and implication for industry to access ACCC tools to Treasury PMO.
Release plan
- 1.16.1 is planned for release on the 18th of March 2022 although is subject to change.
Obligation Dates
- Based on feedback the DSB has finalised obligations dates for future releases.
| Obligation Milestone | Original proposal | Final dates |
|---|---|---|
| Y22 #1 | 14th Mar 2022 | 31st Mar 2022 |
| Y22 #2 | 9th May 2022 | skip |
| Y22 #3 | 11th Jul 2022 | 4th Jul 2022 |
| Y22 #4 | 12th Sep 2022 | 31st Aug 2022 |
| Y22 #5 | 14th Nov 2022 | 15th Nov 2022 |
| Y23 #1 | 13th Mar 2023 | 7th Apr 2023 |
| Y23 #2 | 8th May 2023 | 8th May 2023 |
| Y23 #3 | 10th Jul 2023 | 10th Jul 2023 |
| Y23 #4 | 11th Sep 2023 | 11th Sep 2023 |
| Y23 #5 | 13th Nov 2023 | 13th Nov 2023 |
| Y24 #1 | - | 11th Mar 2024 |
| Y24 #2 | - | 13th May 2024 |
| Y24 #3 | - | 15th Jul 2024 |
| Y24 #4 | - | 9th Sep 2024 |
| Y24 #5 | - | 11th Nov 2024 |
Maintenance / Release Process Changes
- OAS 3.0 files will be published in parallel to OAS 2.0
Open / Active Decision Proposals
The following decision proposals are open for community feedback
| DP # | Closing date | DP |
|---|---|---|
| 229 | Placeholder | Decision Proposal 229 - CDR Participant Representation |
| 225 | 18/02/2022 | Decision Proposal 225 - Data Recipient Security Standards |
| 211 | Pending | Decision Proposal 211 - Scope of Risk-based Authentication and Identity Proofing Framework, Threat and Attack Model |
| 210 | Pending | Decision Proposal 210 - Transition to FAPI 2.0 Profile |
| 203 | No closing date | Normative Standards Review (2021) |
Iteration 10 Issues
All open change requests can be found here: Standards Maintenance Issues.
The standards maintenance backlog can be found here: Data Standards Maintenance
Iteration 10 Progress
The following change requests are currently in the design stage for this iteration
Backlog change requests
The following change requests have been proposed for this iteration. These will only be considered once iteration candidates have been addressed:
Any other business
Meeting Minutes
Notes
Obligation Dates
- The following dates will be made available and linked to an appropriate section within the standards, the standards themselves won't be updated.
| Obligation Milestone | Obligation Date |
|---|---|
| Y22 #1 | 31st Mar 2022 |
| Y22 #2 | skip |
| Y22 #3 | 4th Jul 2022 |
| Y22 #4 | 31st Aug 2022 |
| Y22 #5 | 15th Nov 2022 |
| Y23 #1 | 7th Apr 2023 |
| Y23 #2 | 8th May 2023 |
| Y23 #3 | 10th Jul 2023 |
| Y23 #4 | 11th Sep 2023 |
| Y23 #5 | 13th Nov 2023 |
| Y24 #1 | 11th Mar 2024 |
| Y24 #2 | 13th May 2024 |
| Y24 #3 | 15th Jul 2024 |
| Y24 #4 | 9th Sep 2024 |
| Y24 #5 | 11th Nov 2024 |
Iteration 10 Design Items
AEMO endpoints
- In Meeting 2, documentation for Secondary Data Holder APIs was requested to clarify design. AEMO has clarified where information can be found and updated references to the Standards as the authoritative source. The standards will be updated as soon as possible to include an explicit representation of the APIs, further elaborating on the Endpoint variations described in the Shared Responsibility section for Energy.
MI10 Candidates
Register
- Issues discussed in the last Maintenance Iteration 10 call will continue to be collaborated online through the standards-maintenance GitHub repo. Today we will focus on the remaining issues not yet started.
Issue 444 - Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API
One of the key use-cases for having a public GetDataHolderBrands API is to allow public clients to discover data holders in the CDR and their respective product reference data, status, and outage endpoints. This is a key requirement for comparison sites.
ACCC described an interim solution to making GetDataHolderBrands an unauthenticated endpoint (involves non-trivial changes affecting other endpoints) which requires the development of a new endpoint with a limited number of fields to make PRD endpoints available. Suggested fields:
- Brand name
- PRD URL
- Logo
- Industry
Justification for a new endpoint is based on Data Holder obligations to provide Product data ahead of Consumer data and before they are fully onboarded.
Providing an API allows multiple data sources to be updated when a new onboarding approach is rolled out to support data holders who have only reached the stage of publishing PRD information and are yet to share consumer data.
Industry requests:
- the addition of a unique brand ID because Brand Name is not static and need to reflect changes over time
- Legal entity id so that relationship to other brands and white labelling arrangements can also be discovered
Challenge for ACCC to generate a unique ID that can remain constant over time at this stage of the data holder's involvement in the CDR ecosystem.
Status and outage information can also be retrieved, not just PRD. Allows for red/amber/green style dashboard. Issue #444 will remain open for work to continue on changing GetDataHolderBrands to an unauthenticated endpoint as requested.
- ACCC to publish a description of the new unauthenticated API on the issue and address industry requests.
And;
Expected behaviour for unsupported scopes has been described in a Zendesk article - Expected behaviour for scopes presented by an ADR to a DH – Consumer Data Standards Australia (zendesk.com), they should be ignored.
It was never the intention of the standards to produce a DH specific SSA for ADRs, allowing ADRs to request one SSA and use it to register with as many DHs as possible within the timeframe.
Concern that Zendesk articles are not binding and this statement needs to be more explicit. Vendor experience with banking DHs is that SSAs containing unsupported scopes may result in DCR failing for some data holders due to behaviours of authorisation servers. Conceivably scopes could be a configurable field and changes in this field would not be coupled to an SSA version.
Concern that SSAs could become unmanageable if changes keep occurring and needs to meet the objective of the Register legitimising the ADR
There is a need to distil this issue into several problems
-
DSB to set expectations for data holder behaviour when receiving registrations with unsupported authorisation scopes. This is being addressed in Issue 488
-
DSB to work through what future controls on authorisation scopes are required and how stakeholders may manage them
- What control will the ACCC Registrar need to configure authorisation scopes per software product?
- What control will ADRs need to limit scopes that a software product will use in the ecosystem?
- What are the extensibility requirements where data holders could conceivably add authorisation scopes requirements to their clients through extensible APIs Extensibility
- DSB to discuss internally what evidence can be presented to determine whether DHs will be non-compliant when scopes grow
Issue 443 - SSA definition: Deprecation of revocation_uri
DSB presented a default position:
-
New fields get added and removed with 6 month lead times and FDO's defined
-
Changes are grouped where possible and versioned utilising the x-v pattern
-
Authorisation scopes (which may need to be controlled by an ADR or the registrar) changes do NOT impact the SSA version
-
Data holders will return fields if supported, ignore and not return if not supported
-
Data recipients can validate the registration functionality by the fields which are supported
-
DSB to document default position on SSA change management for the community to review
Energy
-
423 Review of demand charges in energy billing transactions
- No issues raised in regards to the proposal of no change
-
438 Representing adjustment transactions within the Billing Payload for C&I customers
- No further feedback raised
-
439 Review Pricing Model & Time Zone attributes within Account Detail Payload
- DSB has posted a comment on the CR and is seeking feedback from industry. No feedback raised in the meeting.
-
448 EnergyPlanDiscounts contains optional fields that should be conditional
- No issues raised with the proposed change
- Next step is to progress to standards staging
-
449 EnergyPlanSolarFeedInTariff days field should be mandatory
- No issues raised with the proposed change
- Next step is to progress to standards staging
-
457 Get Service Point Detail register suffix should be optional
- No issues raised with the proposed change
- Next step is to progress to standards staging
-
472 Modify Energy Plans structure to allow Time of Use based Controlled Load rates
- Feedback provided to include start and end dates. DSB will assess and address accordingly.
- New issue to be raised for consistent representation of ENUM values for 'days' across sectors and within energy endpoints
-
476 Modify Energy concessions structure to allow non-fixed (e.g. daily, monthly etc.) concessions
- Concession rates in Energy are not calculated like interest rates are in Banking. They are applied to derive a discount associated with the concession.
- No further feedback raised
- DSB to update change request comment with link to ISO 8601 Durations
-
477 Secondary Data Holder Planned Outages and Status
- No further feedback raised
-
478 Energy Secondary Data Holder & Application Specific Errors
- The thread was locked due to comments not aligning with the community code of conduct
- The community was reminded of the need to comply with the Rules of engagement and GitHub Code of Conduct when contributing to the discussion
- Thread will be re-opened for further feedback however DSB will lock the thread again if needed.
Information Security
-
405 Alternative mechanisms for OTP
- Consultation had commenced in MI9 however it couldn't be completed within the timeframes
- There are a number of CX related considerations and CX work will commence at the end of March
- Adjacent issues such as FAPI 2.0 also need to be considered
- These will feed into a targeted Decision Proposal on authentication uplift to the CDR
-
435 Nominated representatives
- This item was initially considered in MI9 where the options described in the ticket were discussed
- Seeking input from participants on preferred option from what was presented in the CR
- Participants acknowledged significant issues where required information from different sources became tangled and awkward.
- Biza/Participant to provide comments for further consideration
- Additional discussion on a separate CR regarding names account holders for joint accounts.
- 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
-
458 Non normative examples
- Where there is a transition from one non normative example to another both will be included in the Non Normative examples tab.
- DSB to include examples to describe the transition to FAPI 1.0
New Actions
- 472 DSB to raise new issue to assess consistent representation of ENUM values for 'days' across sectors and within energy endpoints
- 476 DSB to update change request comment with link to ISO 8601 Durations
- 435 Biza/Participant to provide comments for further consideration
- 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
- 458 DSB to include examples to describe the transition to FAPI 1.0
- 444 ACCC to publish a description of the new unauthenticated API on the issue and address industry requests.
- 488 DSB to set expectations for data holder behaviour when receiving registrations with unsupported authorisation scopes.
- 488 DSB to discuss internally what evidence can be presented to determine whether DHs will be non-compliant when scopes grow
- 486 DSB to work through what future controls on authorisation scopes are required and how stakeholders may manage them
- 443 DSB to document default position on SSA change management for the community to review
Any other business
Next Steps
DSB to update each issue with the proposed solution for detailed discussion in Meeting #4 on 30 March 2022