Date and time: 20/10/2021, 2pm - 3.30pm AEDT (1pm - 2.30pm AEST)
Location: WebEx
Dial-in details:

• https://treasuryau.webex.com/treasuryau/j.php?MTID=m6786d3cadd2da38bd3ae2bf7cca07212
• Dial In Number: +61 2 9338 2221
• Dial In Access Code: 265 1917 2241
• Quick Dial: +61-2-9338-2221,,26519172241##

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 (AEDT)
• Outstanding Actions
• Release plan: schedule of forwards looking standards releases
• Open Decision Proposals: key consultation dates
• Iteration 9 change request candidates
• Any other business

Meeting notes

• Meeting Notes
• Next steps

This week is the fourth call of the 9th maintenance iteration. The purpose of the meeting is to discuss options for iteration candidates adopted in the 9th maintenance iteration. Please note: This maintenance iteration has been extended by 4 weeks and will conclude 1st December 2021. This is to incorporate energy change requests and align to end of year shutdown.

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

• WBC to create proposed featureType descriptions for each enumerated featureType proposed in issue 401
• ANZ to create a change request to better support cursors for returning large result sets.

• v1.12.0 was published on October 14th 2021. This release contains binding non-functional requirements for banking and energy
• v1.13.0: Porting of Register standards from ACCC
• v1.14.0: Energy API standards

The following decision proposals are open for community feedback

DP #	Closing date	DP
216	Pending	Decision Proposal 216 - Profile Scope Support
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	16/11/2021	Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile
206	Closed	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

All open change requests can be found here:

• Standards Maintenance Issues.
• CDR Register change requests.

• Maintenance Iteration 9 extended until 1st December 2021
• Proposed that Maintenance Iteration commence 16th Feb 2022

The following issues have been consulted on during this iteration. The current status is summarised.

Source	#	Change Request	Status	Recommendation
Standards Maintenance	Issue 404	Profile scope not aligned with CX standards	Pending DP	This issue will be consulted on in Decision Proposal 216 - Profile Scope Support given the breadth of the standards changes
Standards Maintenance	Issue 395	Does DHs' PAR endpoint require enabling private key jwt client authentication in addition to request object validation?	No change	No change
Standards Maintenance	Issue 397	Transaction Security Ciphers	Alternative supported	Defer to FAPI 1.0. The change proposed by the DSB to defer to FAPI standards will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption
Standards Maintenance	Issue 406	Change Request to make 'scope' optional in the token end-point response in FAPI	Not supported	Retain current requirement for scope support. Alignment to FAPI 1.0 (Final) requirements for the scope value will be included in the DP 209 consultation. Standards will be changed in accordance to the schedule for FAPI 1.0 adoption
Standards Maintenance	Issue 150	A loan may have no end date but loanEndDate is mandatory	Supported - Breaking Change	Change repaymentFrequency, loanEndDate and nextInstallmentDate fields to be optional.
Standards Maintenance	Issue 396	Define new Digital Wallet Payee Type to relevant schemas	Supported - Breaking Change	Extend payee support for provider-agnostic digital wallets. Get Payees v2 and Get Payee Detail v2 future-dated obligation of 31st of March 2022. Data Holders can support v2 as early as is practical but no later than 31st of March 2022. Retirement of v1 APIs 1 month after v2 FDO (i.e., any time after 31st April 2022).
Standards Maintenance	Issue 405	Alternative mechanisms for OTP	Under consultation	No recommendation yet made
CDR Register	Issue 174	Update Register APIs to search for and differentiate between archived entities	Delayed	Carried over to next iteration
CDR Register	Issue 126	Consider changing statement in Certificate Management about the use of ACCC CA issued certificates for ADR end points	Delayed	To be consulted on under DP 211 threat modelling
CDR Register	Issue 123	Consider identicons to allow DHs to provide multiple attributes to map to individual accreditations	Under consultation	Requesting feedback. No recommendation has been made.
CDR Register	Issue 175	Publish an endpoint version schedule to document the introduction and deprecation of Register and DCR endpoints	Documentation enhancement	This will be covered with the merging of the CDR Register standards into the Consumer Data Standards. Deprecation schedules for various endpoint versions can then be discussed in future maintenance iterations
Standards Maintenance	Issue 407	Align data quality NFR with Privacy Safeguard 11	Change supported	Changes to Data Quality NFRs working in line with OAIC feedback regarding data quality requirements in relation to Privacy Safeguard 11
Standards Maintenance	Issue 402	Support for multiple additional information documents	Change proposed; Under consultation	Proposes changes to supported multiple additional product documents
Standards Maintenance	Issue 401	Extending the list of supported feature types	Under consultation	Proposes changes to supported feature types
Standards Maintenance	Issue 292	Credit card balance plans and payment hierarchy: inadequate information within the CDS	Under consultation	Proposes changes to supported multiple payment plans and balances
Standards Maintenance	Issue 391	Remove requirement for at least one address in physicalAddresses array	Under consultation	Proposed change to remove requirement of at least one address to be returned. Feedback from DHs has indicated that this is not always possible when the address held on record is invalid
CDR Register	Issue 169	Update Register APIs to search for and differentiate between archived entities	Change supported	Documentation fixes. Staged and published after v1.13.0 release
CDR Register	Issue 189	RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified	Change supported	Documentation fixes. Staged and published after v1.13.0 release
CDR Register	Issue 188	SSA definition: Deprecation of revocation_uri	Change supported	Documentation fixes. Staged and published after v1.13.0 release
CDR Register	Issue 186	Documentation improvement: JWT Signature verification requirements during the DCR flows	Change supported	Documentation fixes. Staged and published after v1.13.0 release

---

No new items for discussion

---

ID token producing different sub for the same user logged on

For discussion.

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

• For discussion

Issue 391: Remove requirement for at least one address in physicalAddresses array

For discussion:

• On the Implementation Call a participant raised the issue for free-form address string format

• Address any other business arising from the community

---

Register Issues No issues discussed

Standards Maintenance Issues

• Maintenance iteration extended until December 1st 2021

• ID token producing different sub for the same user logged on

  • Issue relates to business agents of a business consumer (non-individual)
  • Persons nominated to operate (share data) on behalf of a business consumer can be assigned by the business where the Data Holder supports such functionality
  • Data Holders may offer up general "users" that are role based e.g. Payroll Officer, CFO and each of these may have limits on the accounts they can see, select and share
  • Data Holders may also offer up nominated user accounts that are assigned to a named individual
  • Where named individuals are sharing data on behalf of the business, it is unclear how the ID Token and consumer data (specifically the Customer API data) are to be shared
  • Currently there is a coupling of ID Token, user subject and Customer API
  • The business agent's individual details are currently exposed via the agentFirstName, agentLastName and agentRole values in the Customer API
  • Potentially better to decouple this and only pass that data in the ID Token keeping the Customer API as specific to the consumer (i.e. the business)
  • Unclear if multiple nominated business agents collect data with the same ADR if that data is transferable or relatable. The business agents are still operating under the one consumer
  • It is understood at present that data collected by one business agent cannot be connected or transferred to another business agent of the same consumer
  • This forces ADRs to delete or deidentify any previously collected data if/when a business agent leaves the organisation
  • DSB to clarify if the Rules permit sharing of data across business agents
  • If this is permitted, the pairwise identifiers for accounts and resource IDs can remain the same across all business agents and a change request will be created by the DSB
  • If this is not permitted, the pairwise identifiers are different for each business agent and data cannot be correlated across different business agents
  • ID Tokens would have a unique subject representing the individual (i.e. the business agent)
  • Community proposed decoupling ID Token (representing the person) from the data (representing the consumer). This way the ID Token is explicitly related to the individual (either the individual consumer or the business agent) and the Customer API data is explicitly related to the consumer (either the individual or business).
  • Discussed the language used for profile and Customer is ambigious and "profile" is used to mean the line of business the consumer operates in vs the "user profile". This has led to some confusion whether a profile step occurs before (or part of) authentication, or as part of authorisation.
  • DSB will create a change request to clarify the definitions of customer/consumer/user/profile

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

  • Loyalty cards are a specific feature customers want and one of the reasons they select to take up offers on certain products
  • Currently limited detail provided via the CDR APIs on loyalty data (both PRD and account)
  • Where data is provided, it is mostly free-form text
  • This has led to inconsistency across holders and ADRs have had to source this PRD data elsewhere (often screen scraping websites)
  • Proposed that a more structured definition is offered
    • Include currency of the rewards scheme (e.g. VELOCITY POINTS, QANTAS POINTS, proprietary, etc.)
    • Include earn rate with support for tiering (may be amount spent, capped, tiered)
    • Balance for the account the rewards scheme is attached to
    • Often times, PRD features for rewards are tied to an introductory offer (e.g. 20,000 points on sign up)
  • Loyalty scheme account data is not currently designated. This could be offered as a voluntary standard for accounts and loyalty wallets that is optional for banks to implement.

• Issue 391: Remove requirement for at least one address in physicalAddresses array

  • No further issues raised.
  • Noted that free form text addresses must still be compliant and valid addresses so unlikely to achieve the desired outcome of providing an address where the structured address is invalid

• Address any other business arising from the community

Actions

• (#291) Stay Or Go to provide examples of loyalty scheme data
• (#291) DSB to propose initial structure for consultation
• (IDToken) DSB to create a CR for customer definition
• (IDToken) DSB to seek clarification regarding rules for nominated representatives

None

DSB will follow up with Treasury re: business agents for nominated representative scenarios