Date and time: 08/09/2021, 2pm - 3pm AEST
Location: WebEx
Dial-in details:

• https://treasuryau.webex.com/treasuryau/j.php?MTID=md2844e32bbac294d42779fead7663f79
• Dial In Number: +61 2 9338 2221
• Dial In Access Code: 165 569 9964
• Quick Dial: +61293382221,,1655699964%23%23

Chair: Mark Verstege, DSB; Ivan Hosgood ACCC
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 212

• Wait 5 minutes for all participants to join. Kickoff at 2:05pm
• Introductions
• Outstanding Actions
• Release plan: schedule of forwards looking standards releases
• Open Decision Proposals: key consultation dates
• Iteration 8 retrospective
• Iteration 9 change request candidates
• Any other business

Meeting notes

• Meeting Notes
• Next steps

This week is the first call of the 9th maintenance iteration. The purpose of the meeting is to perform a retrospective of the 8th maintenance iteration and to identify iteration candidates for the 9th maintenance iteration

• Allow 5 min for participants to join
• Housekeeping
• Overview, purpose and intended outcomes of the meeting

• DSB to confirm designation of Digital Wallets
• DSB to update Issue #240 with the outcome of discussions with the Treasury Rules team
• DSB to confirm designation of Loyalty schemes data
• WBC to create a change request regarding ADR requirements to implement access token revocation
• ANZ to create a change request to better support cursors for returning large result sets.
• Cuscal to create a change request to address the CX standards gap for the 'profile' scope

• v1.11.0 was published on June 30th 2021 incorporating CX standards changes and the approved change requests from the 7th maintenance iteration
• v1.11.1: In final stages. This release contains minor documentation errata
• v1.12.0+: There is no v1.12.0 currently planned.

The following decision proposals are open for community feedback

DP #	Closing date	DP
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
209	Pending	Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile
208	10/09/2021	Decision Proposal 208 - Binding NFRs
206	10/09/2021	Decision Proposal 206 - Register Standards
203	No closing date	Normative Standards Review (2021)
158	Closed	Decision Proposal 158 - Participant capability discovery

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

A link to the retro board is available here: https://miro.com/app/board/o9J_lyKmRl4=/

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

CDR Register change request issues.

Four changes have been carried over from Iteration 8

• A loan may have no end date but loanEndDate is mandatory
• Define new Digital Wallet Payee Type to relevant schemas
• Credit card balance plans and payment hierarchy: inadequate information within the CDS
• Credit card loyalty program data: significant gaps and lack of structure

The following change requests have been recently raised:

• Alternative mechanisms for OTP
• Profile scope not aligned with CX standards
• Allow lists terms and conditions URIs in additionalInformation for the Product APIs
• Consider additional featureType enumerated values
• Transaction Security Ciphers

• Extend this call to 90min to accomodate Register standards

• Address any other business arising from the community

---

CDR Register

• Introduced inclusion of the CDR Register issues for consultation within a single iteration process
• Release 1.12.0 is likely to include the move of the CDR Register standards into the Consumer Data Standards but this is still to-be-deteremined
• Register issues #174, #126 and #123 will be added as Iteration Candidates
  • 174 - Update Register APIs to search for and differentiate between archived entities
  • 126 - Consider changing statement in Certificate Management about the use of ACCC CA issued certificates for ADR end points
  • 123 - Consider identicons to allow DHs to provide multiple attributes to map to individual accreditations

Iteration 8 Retro

• Open until COB tomorrow for further input. Current feedback is available here: https://miro.com/app/board/o9J_lyKmRl4=/

Iteration Candidates

• #405 - Uplift to OTP authentication

  • Currently the data standards require the consumer to enter the OTP
  • Proposal to allow out of band authentication where the OTP is verified via an authenticator app using a push-to-approve mechanism

• New Item

  • Request was made for a public API to expose non-sensitive Data Holder metadata
  • This would give third-parties an authoritative source of active / accredited participants both ADRs and DHs.
  • For third-parties collecting PRD data, they can source authoritative PRD APIs directly from the Registrar and know the current status plus the Registrar issued identifier for each DH
  • currently metadata relating to DHs and accreditation status of ADRs is public via the CDR Register website but not in a machine readable format (i.e. API)
  • For this to be progressed, it was requested that the participant raise a change request on the CDR Register issue tracker

• #404 - Profile scope

  • There is a gap between the InfoSec standards and the CX data language standards
  • Agreed to prioritise this issue to resolve the gap because it has impact to consumer consent

• #402 - Support for multiple additional information documents

  • Sometimes there is more than one disclosure document related to a product - such as the terms and conditions for a credit card may include the primary T&C for the card as well as a secondary document URI for the complimentary insurance for the credit card (e.g. travel insurance)
  • Discussed whether a list of additional info should be supported
  • If so, should there be structure (e.g. type of document and/or PRIMARY/SECONDARY treatment of documents)
  • Discussed whether all additional info responses should support a list because that way it allows DHs to provide eligibility criteria / legal documents / privacy documents etc. where there are multiple documents describing a product or feature. This would maximise extensibility. to be considered as a proposed option

• #401 - Extending the list of supported feature types

  • Discussed whether a subType should be supported that can be specific to each DH. This would maximise competition and flexibility under a set of industry recognised and defined types
  • Discussed whether there was a source of industry defined types
  • Noted that DHs are responding inconsistently to PRD responses where different constraints or features mean the same thing. For example some DHs describe the fees on closure of a home loan to be EARLY_TERMINATION_FEE vs EXIT_FEE etc. Standardisation will aide comparison but it requires industry agreed terms to be defined and adopted
  • Recognised this is a broader issue where there are many areas of PRD where a lack of structure makes it hard for DHs to expressively and comprehensively describe their products in a manner that is easy to compare programatically
  • It was suggested that rather than try to agree of all industry terminology at once, select a few discrete problems or terms and work through them to agreement. Continue to tackle categories once at a time.
  • Identify broad categories where structure is required

Iteration Call duration

• Agreed to extend the call to 90 mins. This will allow sufficient time to discuss Register issues if the time is required
• Will result in a reduction of meeting time in the long run with the retirement of the CDR Register calls on alternate weeks

• None

• Iteration call will be extended to 90 minutes to accommodate consultation of the Register issues