DSB Maintenance Iteration 12: Agenda & Minutes (17 August 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki

Date and time: 17/08/2022, 2:00pm โ€“ 4:00pm AEST

Location: Microsoft Teams Meeting

Dial-in details:

Chair: James Bligh, DSB

Maintenance overview: Further information

Maintenance project board: See here

Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 259: Maintenance Iteration 12

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
  • Open / Active Decision Proposals
  • Maintenance Iteration 12 Issues
  • Any other business
  • Next Steps

Meeting notes

Introductions

This meeting is the third in the series for Maintenance Iteration 12. The purpose is to provide details on the proposals for each change request under consultation in this iteration.

Outstanding Actions

Energy

InfoSec

  • DSB (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.
    • Waiting on advice
  • CBA to raise a change request to drop encryption for the JARM token response. Issue #458
    • Waiting on advice

Other

  • MI11 RETRO: DSB to consider the adoption of a feedback loop from community to assist in the prioritisation of maintenance iteration candidates and advise.
  • MI11 RETRO: DSB to consider a process to summarise the current position on a change request as it is iterated on to avoid confusion and advise.

Release plan

Open / Active Decision Proposals

The following decision proposals are open for community feedback

  • Closing date for DP263 was missing when the agenda was published, it has now been updated.
DP # Decision Proposal Closing date
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date Link to consultation
Noting Paper Noting Paper 255 - Approach to Telco Sector Standards Link to consultation
Noting Paper Noting Paper 258 - Independent Information Security Review Link to consultation
Consultation Decision Proposal 260 - Energy Closed Accounts Feedback extended, now closes: 30th of August 2022 Link to consultation
Consultation Decision Proposal 262 - Telco Product Reference Payloads Feedback closes: 5th of September 2022 Link to consultation
Consultation Decision Proposal 263 - Telco Accounts Payloads Feedback closes: 16th of September 2022 Link to consultation
Consultation Decision Proposal 264 - Telco Invoice Payloads PLACEHOLDER Link to consultation
Consultation Decision Proposal 265 - Telco Billing Transactions Payloads PLACEHOLDER Link to consultation
Consultation Decision Proposal 266 - Telco Balance and Usage Payloads PLACEHOLDER Link to consultation

Future Plan

Review of July-September Quarter and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1

Maintenance Iteration 12 Issues

All open change requests can be found here: Standards Maintenance Issues.

The standards maintenance backlog can be found here: Data Standards Maintenance

The change requests proposed for this iteration are:

InfoSec

Register

NOTE: Issue #480 and Issue #484 have been removed from MI12 at Biza's request.

CX

Energy

Banking

MI 12

Any Other Business

Meeting Minutes

Notes

Outstanding Actions

Energy

  • DSB/AEMO Issue #477 DSB and AEMO to meet offline and agreed on a date the APIs will be available.
    • This is included in MI12. FDO is not relevant because the proposed APIs are not in the standards however DSB and AEMO will provide an update when a delivery date has been confirmed.
  • Retailers to raise a ticket on energy usage data covering multiple FRMPs. DSB to table this in their discussions with AEMO.
    • Analysis delayed, will be picked up after the Energy sector is implemented in November.
  • DSB to raise "Issue #475 - Energy - Representation of Spot price based contracts for C&I customers" at the next AEC meeting
  • DSB will progress "Issue #520 - Stepped solar feed in tariffs in Energy" and propose options for consultation
    • Ongoing.

InfoSec

  • DSB (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.
  • CBA to raise a change request to drop encryption for the JARM token response. Issue #458
    • Waiting on advice

Other

  • MI11 RETRO: DSB to consider the adoption of a feedback loop from community to assist in the prioritisation of maintenance iteration candidates and advise.
  • MI11 RETRO: DSB to consider a process to summarise the current position on a change request as it is iterated on to avoid confusion and advise.
    • When a solution has been identified on a CR a section titled 'DSB Proposed Solution' will be added to the issue description linking to the comment describing the current proposal. This link will be updated as the proposal evolves. A 'proposal made' tag will also be added to the issue so its easy to track. See Issue #414 as an example.

Release plan

Maintenance Iteration 12 Issues

The change requests proposed for this iteration are:

InfoSec

  • Issue #411 - Clarification of x-fapi-interaction-id header

    • Agreement was to choose the simplest option and align directly to FAPI language
    • Exploring a CDS specific header could be consulted on as part of the FAPI 2.0 migration because FAPI 2.0 drops support for the x-fapi headers

  • Issue #435 - Nominated representative end user for non-individual consumers

    • Discussed options for dealing with agent data (nominated representative data).
    • General consensus to decouple agent data from consumer data and OIDC
    • Also discussed removing user agent from the Customer API as a temporary measure then consult on broader changes in future. This was problematic because it may result in additional implementations costs and drop the current support for the agent role information
    • Removing agentRole would align simply to the OOTB OIDC scopes
    • Whilst supporting agent data via OIDC claims was discussed this was considered less preferred because it would increase dependencies on OIDC whilst FAPI 2.0 seeks to be independent of OIDC
    • Adding a new Get User API would be the best long term solution if agentRole is required and allows business use cases to evolve
    • Proposal should ask if a separate scope is required
    • Discussed whether power-of-attorney solutions should be supported via a flag
    • Given this would introduce a new API, it was considered that a DP would be the preferred option to progress this consultation

  • Issue #447 - CORS typos in CDR

    • General consensus is to adopt line 5125 change without the informational comments.
    • The information changes are incorrect because the do not consider MTLS protections and will cause conflicts if the statements are adopted for all endpoints

  • Issue #458 - FAPI 1.0 Non Normative Examples

    • Not discussed

  • Issue #479 - Clarification on Minimum Algorithm Required for JARM

    • Not discussed

  • Issue #522 - OpenID Provider Configuration End Point parameter requirements

    • Not discussed

Register

  • Issue #409 - Dynamic Client Registration Response Time NFR

    • Support for extended NFRs focused on relief for DHs
    • Generally participants acknowledged that whitelisting isnโ€™t intrinsically part of DCR
    • Banks discussed the reasons for whitelisting outbound calls to protect systems and ensure there is selective access to the internet based on internal security controls and processes.
    • Extending the NFR would allow for some DHs to automate whitelisting at the time of DCR request.
    • The concern of extending this time is the scalability and performance of the ecosystem.
    • There was limited justification why other compensating controls cannot be used to mitigate security risks. It was requested that participants that are performing automated whitelisting to expand upon their reasons to progress the issue

  • Issue #525 - softwareProductDescription should be marked as mandatory

    • The ACCC explained this is not a breaking change, it's an uplift to the payload to make the field mandatory. This aligns with onboarding processes where this field is 'Required' in the CDR Participant Portal.

CX

  • Issue #529 - CX - Energy Data Language Standards - NMI and Scheduled Payments
    • This issue was not discussed in the Maintenance Iteration call. However by way of update:
      • the DSB has received support for the proposed change from Biza, Red Energy, and Energy Australia. We are still seeking input from other energy retailers, particularly those with November obligations, to understand if there is consensus. We have received verbal support from other retailers but request that these views be submitted on 529. If there is consensus for the change to take effect from November, we will propose the change be treated as urgent and dealt with separate to MI12.

Energy

Banking

MI 12

Other Business

  • No other business items raised.

New Actions

There are no new actions although DSB will update each change request with the discussion outcome. Correction, the following actions are new for this meeting.

Next Steps

We are in the middle of this MI, we have some proposals outstanding and will prioritise those issues that haven't been discussed in the next meeting. We encourage the community to provide feedback to facilitate proposal development.

DSB will update each change request with the discussion outcome.