-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 9: Agenda & Meeting Notes (8 September 2021)
CDR API Stream edited this page Sep 8, 2021
·
7 revisions
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
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