Meeting Notes

Release Plan

• The changes arising from Maintenance Iteration 19 were published in v1.31.0 on 3 July 2024.
• The outcome of Maintenance Iteration 20 will likely be published in v1.32.0.

Requirements Analysis

Security

• #628 - Addition of a DH-side endpoint for querying the status of a consent establishment flow
  • RECAP This issue was first raised in MI18 and taken offline to explore authentication and authorisation drop offs with ADRs. Aside from legitimate reasons a consumer may choose not to proceed during this flow, the objective was to look for discrete issues and potential solutions to unintended drop offs. A report on the outcomes was presented to DSAC, the report is available in this comment.
  • The mix of potential solutions overlaps with work being undertaken in the Information Security and NFR Consultative Groups however it is desirable to identify fixes that could be progressed ahead of broader solutions to alleviate the burden on ADRs.
  • One participant suggested that drop offs is the # 1 point of friction, failure and frustration for ADRs by a factor of 10.
  • Consensus in the meeting was to avoid patching solutions.
  • A potential solution for one of the related problems is #649 Inconsistent JARM error responses see Errors section below.
  • The DSB intends to explore the recommendations presented to DSAC in MI20 to assess which ones can progress.

Banking

• #636 - Remove BankingTransactionDetail and incorporate extendedData into BankingTransaction
  • Outstanding actions are in progress.
  • ACTION: DSB to follow up with Dima on NPP opinion.
  • ACTION: DSB to schedule offline discussion with SISS (Josh) on data quality analysis.

Common

• #610 - Addition of an (18 or over) Age Verification Flag
  • A status on this issue was requested, DSB confirmed it's on the backlog for further assessment but unlikely to be progressed in this Iteration due to capacity constraints.

Maintenance Iteration 20 Candidate Selection

Holistic Changes

• #647 - Maintenance Iteration 20 Holistic Feedback
  • A number of minor fixes have been posted on this issue, they are simple typos that will be corrected.

Maintenance Iteration 20 - Proposed Candidates

CX

NOTE: The knowledge article mentioned in the meeting, providing details on CX Guidelines Consultation, was published later in the day.

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

  • Carried over from MI19
  • Outstanding actions are in progress
  • 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.

• #646 - Clarify selection of Trusted Adviser in the CX Guidelines

  • Candidate

InfoSec

• #648 - Adopt BCP 195 for TLS ciphers

  • Applies to TLS and MTLS
  • FAPI 1.0 is final, however looking to publish errata to accommodate this change.
  • DSB will update the normative reference to FAPI 1.0 to FAPI 1.0 Errata, signalling a change to upstream standards.
  • Candidate

• #650 - Weaken JARM Encryption Requirements for ADRs

  • Initially raised in CDR Implementation Call as a security hygiene issue.
  • Discussion required on whether there are redundant JARM Encryption requirements in the specification.
  • Consider as a candidate for MI20.

Banking

• #553 - Running balance available under transaction detail

  • Participants acknowledged this issue represents a significant challenge in core banking systems therefore providing output for CDR is problematic.
  • Concepts applied to statements could provide insight to solve this issue.
  • Running balance was considered when the Banking standards were drafted in 2018, https://github.com/ConsumerDataStandardsAustralia/standards/issues/28, history may be relevant.
  • Consider as a candidate for MI20

• #641 - Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType

  • Appears to be simple clarification
  • Consider as a candidate for MI20

Energy

• #644 - AmountString field type impractical for energy tariffs
  • This issue raises concern around amount string field type ambiguity and requires conversion for energy tariffs.
  • Intention is to remain consistent across sectors, this intention was supported by a number of participants.
  • String is intended to be dollar dollar dot cents cents format ($$.cc), participants supporting the intended format are requested to comment on the issue.
  • Candidate

Errors

• #651 - Supporting HTTP Status 429 passthrough from Secondary Data Holder

  • Overlaps with issues under consideration in the NFR Consultative Group
  • DSB to determine capacity for the MI before including this a candidate if appropriate

• #649 - Inconsistent JARM error responses

  • Option to resolve one issue also contributing to problems identified in #628 (see Requirements Analysis above)
  • Concern Identity Provider solutions can't be modified to accommodate this requirement
  • ADRs require information to understand what's happening on Data Holder side to assist consumers with troubleshooting failed consent flow.
  • Recommendation to user errorURI not errorDescription as shown in issue.
  • Consider as a candidate for MI20

Documentation

None

Other business

Extensibility of standards and challenges around using the CDR name space.

• DSB to assess priority of this issue in relation to capacity for the MI

Next Steps

DSB will assess priority and determine capacity to address the candidates proposed for consideration in this iteration. The community is invited to comment on issues affecting them.