Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 2nd of December 2021

Jump to bottom
CDR API Stream edited this page Dec 2, 2021 · 4 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

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

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

  • 5 min will be allowed for participants to join the call.

Recording

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.

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.

Updates

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

CDR Stream Updates

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

Presentation

None this week.

Q&A

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

Answer provided

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).

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally