DSB Maintenance Iteration 10: Agenda & Meeting Notes (16 February 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki

Date and time: 16/02/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:

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
  • Future Plan
  • Retrospective on Iteration 9
  • Iteration 10 backlog
  • Any other business

Meeting notes

Introductions

This week is the first call of the 10th maintenance iteration.

The purpose of the meeting is to perform a retrospective of the 9th maintenance iteration and to identify iteration candidates for the 10th maintenance iteration.

  • Housekeeping
  • Overview, purpose and intended outcomes of the meeting

Outstanding Actions

  • ANZ to create a change request to better support cursors for returning large result sets. - Closing, request deprioritised
  • (Issue #292) [IN PROGRESS] DSB to propose strawman solution - To be prioritised as part of MI #10
  • (Issue #291) [IN PROGRESS] DSB to propose strawman solution - To be prioritised as part of MI #10
  • (Issue #418) DSB will consult on a long-term strategic solution to resolve this issue however a short-term solution needs to be embedded to supports ADRs and DHs during the transition - Iteration candidate for MI #10
  • (Issue #418) DSB to verify that the ACCC can or is providing an operational process to distribute ADR domain lists to DHs ahead of activation and DCR requests - Participants encouraged to engage with ACCC's operations team via the CDR Service Management Portal or via the CDR Technical Operations Mailbox.
  • (Issue #426) [IN PROGRESS] DSB to discuss with ADRs whether any are currently allowing token reuse - Addressed in v1.15.0
  • (Issue #428) [IN PROGRESS] DSB to discuss CTS support for audience claim value for DHs calling the ADR revocation endpoint - Addressed in v1.15.0
  • (Issue #428) [IN PROGRESS] DSB to confirm that the ACCC is updating the CTS to test the proposed wording, not the current wording
  • (Issue #433) [IN PROGRESS] DSB to continue discussions with the ACCC on the CTS changes and provide a response back to the community - closed however issue #453 has been raised to discuss the upper limits

Release plan

  • v1.16.0: Released 04/02/2022 incorporating DP 222 and addressing defects from 1.15.0
  • Future release dates yet to be confirmed

Obligation Dates

Proposed obligation windows for 2022

2022
14th March
9th May
11th July
12th Sep
14th Nov
2023
13th March
8th May
10th July
11th Sep
13th Nov

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)

Future Plan

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

Iteration 9 Retrospective

Opportunity for the community to provide feedback on the Iteration #9 process

Feedback received: Extra information in the release notes #464

Iteration 10 Backlog

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

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

Iteration 10 Candidates

The following changes have been carried over from Iteration #9

# Sector/Domain Change Request
Issue 465 Register Confirm Register API 2022 release dates
Issue 452 Register Deprecation and retirement dates for CDR Register superseded endpoint versions needs to be defined
Issue 444 Register Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API
Issue 443 Register SSA definition: Deprecation of revocation_uri
Issue 431 Register Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive #431
Issue 418 Register CDR Data Holders outbound connection whitelisting
Issue 405 Infosec Alternative mechanisms for OTP
Issue 435 Infosec Nominated representative end user for non-individual consumers
Issue 423 Energy Review of demand charges in energy billing transactions
Issue 438 Energy Representing adjustment transactions within the Billing Payload for C&I customers
Issue 439 Energy Review Pricing Model & Time Zone attributes within Account Detail Payload

Proposed change requests

The following change requests have been proposed for this iteration:

# Sector/Domain Change Request
Issue 459 Register Sector Agnostic Register APIs
Issue 292 Banking Credit card balance plans and payment hierarchy: inadequate information within the CDS
Issue 291 Banking Credit card loyalty program data: significant gaps and lack of structure
Issue 462 Banking Make additional account attributes available in bulk standards-maintenance
Issue 463 Banking Account holder name(s)
Issue 470 Banking Overloading of banking language for scopes / data clusters
Issue 471 Banking Additional credit card fields standards-maintenance
Issue 448 Energy EnergyPlanDiscounts contains optional fields that should be conditional
Issue 449 Energy EnergyPlanSolarFeedInTariff days field should be mandatory
Issue 456 Energy Updates required to a property and the example provided in EnergyPlanSolarFeedInTariff schema
Issue 457 Energy Energy - Get Service Point Detail register suffix should be optional
Issue 472 Energy Modify Energy Plans structure to allow Time of Use based Controlled Load rates
Issue 475 Energy Energy - Representation of Spot price based contracts for C&I customers
Issue 474 Energy Update description of energy API attributes (where applicable) to specify which rates are GST exclusive
Issue 476 Energy Modify Energy concessions structure to allow non-fixed (e.g. daily, monthly etc.) concessions

Meeting Minutes

Notes

Future Dated Obligations

  • A proposal was presented by DSB to move towards a predictable obligation schedule. This would mean that all changes introduced in the data standards would be pegged to one of a set of static obligation milestones.

  • In effect this would introduce obligation windows that are known in advance by all participants.

  • Consultation for each change would still discuss the size and complexity of the change to identify the appropriate milestone to choose.

  • The initial proposal selected the second Monday of every second month excluding a shutdown period of the Christmas and New Year period.

  • This proposal considered five obligation milestones each year.

  • Even though a date is proposed, it doesn't mean that changes have to be released on that milestone (e.g. if there are no changes applicable for that period). It simply provides a known window for changes to occur at agreed times.

  • Feedback from participants indicated that for the existing calendar year, selecting appropriate milestones from the already published obligation dates would be more appropriate to limit the number of obligation dates.

  • Moving forwards participants supported the predictability and the proposed second Monday of every second month.

  • Feedback supported avoiding end of financial year and Christmas/New Years.

  • This proposal doesn't include rules / legislative milestones.

  • Dates may be adjusted accordingly if legislative milestones fall near proposed obligation milestones.

  • Based on the feedback, the DSB took an action to come back next meeting with a proposal incorporating the discussion's feedback.

Obligation Milestone Original proposal Updated proposal
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 1st 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

Iteration 9 Retro

  • Issue 464
    • Recommending documentation improvements to help interpret changes between standards.

ACTION: DSB will work through this issue to determine opportunities for improvement.

Iteration Candidates

Iteration candidates are listed by Information Security, Register, Banking and Energy in the following sections.

Information Security

  • Issue 405: Alternative mechanisms for OTP

    • This change will be converted to a Decision Proposal given the scope of change and cross-sector impact

    • This change is dependent on upstream specs related to the FAPI 2.0 migration. As such, the scoping decision proposal for FAPI 2.0 will be consulted on first

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

    • This change relates to the representation of nominated representative data via the UserInfo and Customer APIs. Solution options will be proposed including the removal of nominated representative agent data from the Customer APIs

  • cdr_arrangement_jwt

    • Question raised on the use of HS256 signing algorithm

    • Noted that the algorithm is symmetrical not asymmetrical

    • Participant will raise a Zendesk ticket to seek clarification

CDR Register

  • Register Issue #459

Proposed Change: ACCC has raised a change request on the Register APIs requesting the path parameter used to define industry, be removed. Path parameter to filter by sector is used by GetDataHolderBrands where there is a sector field. However, other APIs, there is ambiguity on what would be returned if a sector field was populated.

Therefore, given ACCC's current implementation, removing the path parameter and collapsing the path is being proposed, relying instead on a query parameter which can be applied for those APIs which return sectors.

Original Solution: The path parameter option was originally chosen to ensure consistency with the current pattern already defined in the CDS, as well as minimising change impact to participants. The simplest change was to not introduce new path patterns into the standards. A enum value of all was introduced to represent a sector agnostic call to these APIs.

Query industry parameter introduces implicit filtering. Path industry parameter maintains explicit filtering.

ACCC's proposal to remove the industry path parameter raises the following questions:

  1. What are the key benefits on such a change to the ecosystem? This CR articulates the benefit to the ACCC Register current implementation but not to other stakeholders/ecosystem?
  2. What is the change impact to the ecosystem? Lots of participants vs 1 register?
  3. ADRs are not currently accredited by sector. Is it a good assumption to make that this is a constant? It seems unlikely that as the expansion of sectors continues, there won't be some form of industry specific accreditation requirements
  4. The register assigns an accreditation number per ADR which has the sector in the naming convention e.g.ADRBNK000001. ACCC response: This is to be removed in the future
  5. Is there consideration to the future where the Register APIs may need to be customised per sector and therefore the path industry field would be required?
  6. What would constitute an x-v version change? When a new sector comes onboard and the sector enumeration is updated, this would result in an x-v version increment for APIs which reference this enumeration. This would apply to both models.
  7. GetDataRecipients doesn't have a natural filter across industries given the absence of a sector field. What are the use cases where a data holder will want a subset of data recipients? The requirements here are unclear and there would be benefit in digging deeper?
  8. What about other filter types such as updated_since?
  9. Should we focus on understanding the use cases warranting filtering and the appropriateness of the mechanism derived from these requirements? Further analysis is required to determine appropriateness of changes. Further work required defining requirements, benefits or the impact to participants (positive or negative).

DSB has now posted an initial response on this CR.

Banking

  • Summary of banking change requests:

    • Discussion focussed on the list of change requests

    • The changes were put to the community regarding priority but no participants offered a view on priority

    • Participants were encouraged to consider the banking CR priorities over the next fortnight to advocate for which, if any, changes should be considered this iteration

  • Issue 291: Credit card loyalty program data: significant gaps and lack of structure

    • Issue 291 was discussed. This issue was carried over from Maintenance Iteration 9 with the intent to consult in MI 10

    • It is thematically grouped with a number of related credit card product change requests that have been raised by the community

    • If this issue is prioritised it would make sense to address the related change requests

  • Issue 292: Credit card balance plans and payment hierarchy: inadequate information within the CDS

    • See comments for #291.

  • Issue 229: Service field in the Get Transaction Details API

    • This issue had been consulted on in a previous and no change was made because banks were not able to identify changes required

    • NAB has taken an action to perform the analysis to identify what changes would be required for the extended payload data to support the updated versions of the X2P1 overlay and SCT

Energy

All energy CRs were discussed and energy participants considered all energy related CRs to be worth of consideration for MI 10. Due to capacity the DSB proposes that MI10 commence with the following energy CRs in scope for consultation:

An additional CR is also being proposed for consultation

The remaining CRs will be included at the top of the backlog to be addressed as a stretch goal in this MI if there is capacity available:

Actions

  • DSB to propose a revised Obligation Milestone schedule incorporating existing obligation dates and community feedback. See Meeting Notes.
  • 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.
  • MoneyTree to post question on Zendesk regarding cdr_arrangement_jwt signing algorithm choice, this will be assigned to DSB who can consider whether existing articles provide answers and if not an article will be written or a change request initiated.
  • Community to indicate priority by voting or commenting on CRs before MI10 Meeting #2 on 2 March 2022.

Any other business

  • None

Next Steps

  • Community to consider priorities for this iteration and comment on each issue accordingly.