DSB Maintenance Iteration 19: Minutes (12 June 2024)

Meeting Minutes

Release Plan

The outcome of Maintenance Iteration 19 will be published in v1.31.0.

Maintenance Iteration 20

There is a 4 week break before Maintenance Iteration 20 commences on 10 July 2024.

Requirements Analysis

Common

• #610 Addition of an (18 or over) Age Verification Flag
  • Requires further assessment.

Security

• #628 Addition of a DH-side endpoint for querying the status of a consent establishment flow
  • Acknowledging Mark Wallis' request for an update in this comment, DSB capacity constraints has meant an update is not available at this time, discussions will continue in MI20 and we hope to be able to provide an update before it commences.

Banking

• #636 Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction
  • Outstanding actions are in progress.
  • A discussion on the anticipated increase in calls for consumers requiring extended data, stemming from this comment, indicates approximately 14 - 20% of transactions would require additional calls to the BankingTransactionDetail endpoint. The calls to collect extended data for these transactions have not yet been made, but are anticipated to commence in the near future.
  • ACTION: DSB to follow up with Dima on NPP opinion.
  • ACTION: DSB to schedule offline discussion with SISS (Josh) on data quality analysis.

Maintenance Iteration 19 Candidates

Holistic Changes

• #638 Maintenance Iteration 19 Holistic Feedback
  • Issue described in this comment will be raised as a new issue.
  • There is 'No change' resulting from this issue.

CX

• #633 Collection Consents - Authorisation Amendment
  • Confirmed there is no impact on Data Holders. Any impacts, expected to be low, will likely affect ADRs if they are not currently passing the cdr_arrangement_id to amend an authorisation request.
  • DSB's proposed option, Option 4, will be adopted.
  • The non-breaking change will be made in v1.31.0.

Energy

• #640 Retirement date for Get Generic Plan Detail v2 and Get Energy Account Detail v3
  • DSBs proposed Retirement date of 3 March 2025, 3 months after the obligation dates for new versions, will be adopted.
  • The non-breaking change will be made in v1.31.0.

Documentation

• #362 Security Profile: Request Object - Inconsistency in example for sharing_duration and cdr_arrangement_id

  • This issue will result in 'No change'.
  • ACTION: Participants requested to advise whether further guidance would be helpful.

• #573 Clarification on handling of standard claims in request object

  • Outstanding actions are in progress.
  • Discussed the expected behaviour of OpenID Discovery Document (OIDD) is for it to be maintained and accurately reflect claims and scopes supported by the data holder. Intention is that ADRs routinely check the configuration before making a request.
  • OUTSTANDING ACTION: DHs to compare what is advertised on their OIDD aligns to their system behaviour and authorisation requests being received to determine if any discrepancies exist and whether ADRs are checking the OIDD before making requests that include unsupported scopes or claims.
  • OUTSTANDING ACTION: DSB to continue analysis of how ADR and DH should handle unsupported scopes in different scenarios.
  • This issue will be carried forward to MI20.

• #415 Disambiguation of the claims for a response from the introspection endpoint

  • A correction to the agenda for 12 June has been made to show this is a 'Non-breaking change' not 'No change'.
  • DSBs proposed solution will adopted.
  • The non-breaking change will be made in v1.31.0.

• #615 Plan Obligation Milestones for 2025

  • Proposed dates for 2025 will be adopted.
  • The non-breaking change will be made in v1.31.0.

Other business

Discussion on Issue #643- Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities

• DSB justified the need to include this Issue as a candidate in MI19 is due to the security implications and alignment with upstream standards.
• Some participants on the call noted they have removed support for the vulnerable ciphers through their own security processes and practices.
• It was suggested the ACCC could potentially help determine which DHs are supporting the ciphers. However the proposed Stage 1 change recommends immediate deprecation by changing moving them from "SHALL be permitted" to "SHOULD NOT be permitted". This would allow data holders to remove support at their discretion.
• Participants supported making Stage 1 changes proposed in the issue as part of this MI release. Stage 2 changes will be consulted on in MI20.

Next Steps

The DSB will finalise solutions on each issue where the requirements have been sufficiently clarified and continue staging changes for v1.31.0.