-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 2nd of December 2021
When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##
Meeting Details:
Desktop or Mobile Devices
https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f
Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.
Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 1650705270@webex.com
Phones - AUDIO ONLY
- Primary Australia: +61-2-9338-2221
- Quick Dial: +61-2-9338-2221,,1650705270##
- Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
- Meeting Number/Access Code: 165 070 5270
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.
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.
Type | Topic | Update |
---|---|---|
CDR Implementation Call | Final call for 2021 is 16th of December 2021 | Updates to calendar invitations to come |
Standards | Version 1.14.0 Published | Link to change log here |
Standards | v1.15.0+ is planned for mid December | Pending any minor tweaks, fixes or amendments to v1.14.0 |
Maintenance | 9th Maintenance Iteration | Agenda from the 1st of December 2021 meet |
Maintenance | Decision Proposal 212 - Banking Maintenance Iteration 9 | Link to consultation |
Maintenance | 10th Maintenance Iteration | To commence on 16th of February 2022 |
TSY Newsletter | To subscribe to TSY Newsletter | Link here |
DSB Newsletter | To subscribe to DSB Newsletter | Link here |
TSY Newsletter | 26th of November 2021 | View in browser here |
DSB Newsletter | 26th of November 2021 | View in browser here |
Consultation | Normative Standards Review (2021) | Link to consultation |
Consultation | Decision Proposal 222 - CX Standards & Insights and Trusted Adviser Disclosure Consents | Link to consultation |
Consultation | Decision Proposal 225 - Data Recipient Security Standards | Link to consultation |
Consultation | Decision Proposal 162 - CX Standards & Joint Accounts | Link to consultation |
Action | DSB Holiday Season Plan | Link to DSB Holiday Season Plan |
Provides a weekly update on the activities of each of the CDR streams and their stream of work
Organisation | Stream | Member |
---|---|---|
DSB | Technical Standards - Energy | Hemang Rathod |
ACCC | CDR Register | Hopeson Chiao |
ACCC | CTS | Andrea Gibney |
ACCC | Onboarding | Christine Atkins |
DSB | CX Standards | Michael Palmyre |
DSB | Technical Standards - Register | Ivan Hosgood |
DSB | Technical Standards - Banking | Mark Verstege |
DSB | Technical Standards - Engineering | James Bligh |
None this week.
Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517
Ticket # | Question | Answer |
---|---|---|
1109 | The GetDataRecipientsStatus API is exposed by CDR Register for Data Holders to check the validity of ADRs. The DataRecipientStatus of the response returned from this endpoint (https://cdr-register.github.io/register/#tocSdatarecipientsstatuslist) is defined as follows. { "dataRecipientId": "string", "dataRecipientStatus": "ACTIVE" } In (https://cdr-register.github.io/register/#ecosystem-entities), above 'dataRecipientId' is described as : - dataRecipientId :Identifier in DataRecipientStatus schema returned as part of GetDataRecipients API. This is the equivalent to the 'legalEntityId' described above. Accordingly, the GetDataRecipientsStatus API endpoint of CDR Register will return the 'legalEntityId' of the ADR as the 'dataRecipientId'. But under Client Registration section (https://cdr-register.github.io/register/#dynamic-client-registration), the 'legal_entity_id' is stated as an optional parameter in the SSA. In such cases, what will be the identifier included by CDR Register as the 'dataRecipientId' in the response of GetDataRecipientsStatus API? Additionally, please explain how a Data Holder should use the response of GetDataRecipientsStatus API to validate their ADR clients who have registered with SSAs that doesn't include the 'legal_entity_id'. |
The dataRecipientId and legal_entity_id are equivalent. The identifiers section of the CDR Register Design articulates that these are duplicate terms. Regarding the legal_entity_id presented in the SSA, this was flagged as optional during the introduction of this field. During this time, the CDR Register would optionally return this field. However, post-July 2021, these fields are now always returned. A future version of the Consumer Data Standards will address this documentation issue in the SSA section of the documentation. |
1206 | Have couple of questions on the scenario when the DH calls DR "CDR Arrangement Revocation End Point" . In the above case, what are the guidelines to DH in case they receive an error response from DR. Specifically, 1. In case DR sends a HTTP 500 error code, is DH supposed to retry by calling the CDR Arrangement Revocation End Point again? 2. Should DH invalidate the tokens associated to "cdr_arrangement_id" irrespective of outcome of CDR Arrangement Revocation End Point call DR? |
When a consumer withdraws authorisation from the data holder dashboard, the data holder notifies the data recipient via the CDR Arrangement Revocation endpoint. The CDR Register design describes the use of back-off patterns so a more robust messaging to the data recipient can occur. Therefore, if a 500 error is encountered, the Data Holder must retry the request, following one of the retry/backoff patterns described. The Data Holder must also prevent consumers from retrieving data using this now deauthorized consent. The design does not dictate the implementation approach however your solution would need to prevent data disclosure against the cdr_arrangement_id. This should not be coupled to the outcome of the call to the CDR Arrangement Revocation endpoint. A failure to notify the data recipient, should not impact the withdrawal of authorisation on the data holder side. |
1222 | We have a query about Joint Account data sharing by vulnerable consumers, here is the scenario: Joint Account holder 1 (JH1) is identified as a vulnerable consumer, and JH1 shared a Joint Account (JA1) as if it were an Individual Account, i.e. other account holders won’t see any detail about this sharing. Later on, JH1 had his/her vulnerable status removed, should the other account holders be updated about all the sharing history/activities of JA1 did by JH1? · If the answer is “No” for the above question: Now JH1 has withdrawn the sharing of JA1 from the consent, and later re-added JA1 for sharing through amending consent process. What would be expected to be seen by other account holders about the sharing history/activities of JA1 prior to JH1’s vulnerable status is removed. |
The rules (and standards) are not prescriptive when it comes to how DHs identify, support, and manage vulnerability - this is because DHs have their own systems and processes and it has been acknowledged that these are not universal nor consistent across DHs. As such, a DH can rely on rule 4A.15 and choose to show (or not) 'the sharing history/activities of JH1' to the other joint account holders. The same applies to future amendments relating to JA1 depending on if/how the DH deems it necessary to omit details to the other joint account holders (to prevent harm or abuse). |
View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.