ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 28th of October 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki

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: [email protected]

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 [email protected] 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
Standards Version 1.13.0 Published Link to change log here
Standards v1.14.0 is now in Standards-Staging Release date: 29th of October 2021
Maintenance 9th Maintenance Iteration Agenda from the 20th of October 2021 meet
Maintenance 9th Maintenance Iteration Extended until 1st of December 2021 Dates updated here on the comment in Decision Proposal 212
Maintenance Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter 22nd of October 2021 View in browser here
TSY Newsletter 20th of October 2021 View in browser here
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile Link to consultation
Consultation Decision Proposal 216 - Profile scope support Link to consultation
Knowledge Data Standards Body YouTube Channel is now Live Link to view our Videos
Knowledge Recording of v1.13.0 Walkthrough Link

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation Stream Member
ACCC CDR Register (Technical) Ivan Hosgood
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None.

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
912a What mechanism do DHs have to send notifications to customer of incorrect data being shared (PS11 and Rule 7.10), when there is no active consent anymore. Rule 7.10 requires the written notice to be given by ‘electronic means’. This means that the notice could be given via email (for example, in the body of an email or in an electronic file attached to an email) or via the consumer’s dashboard. In a situation where there is no longer an active consent, we note that it may not be appropriate to provide the written notice via the dashboard (as the consumer might not actively check their dashboard in such circumstances). While SMS is an ‘electronic means’ of communicating a notice, practically it is unlikely to be appropriate as the number of matters that the written notice must address under CDR Rule 7.10(1) would likely make the SMS very long. For further information, see Chapter 11 (PS 11) of the OAIC’s CDR Privacy Safeguard Guidelines.
912b In terms of sharing corrected CDR data, how will this be orchestrated from the DHs end when the customer requests the DH specifically (Rule 7.10)? An answer to this question is available under the second heading of this article ‘Note on privacy safeguard 11’.
1145 4A.14 Notification requirements for consumer data requests on joint accounts (3) The data holder must, in accordance with any relevant data standards: (a) provide for alternative notification mechanisms schedules (including reducing the frequency of notifications or not receiving notifications); and; (b) give each joint account holder a means of selecting such an alternative, and of changing a selection Question - can you confirm what the frequency of notification means in (a) please?.....if notification is done instantly - is this stipulation that there also needs to be a frequency choice of when notification occurs (i.e. once a monthly/quarter etc) .........the rules specifies "Must" however, this would not seem to be appropriate if the customer has chosen to share data once for example..... Thanks for raising this query here. Apologies for any confusion on last week's call, but I can confirm that the interpretation I gave was correct. Some additional detail on the meaning of 'frequency' below. The default requirement in 4A.14(2) is to provide the appropriate approval notification ‘as soon as practicable after the event occurs’. This is what 'frequency' refers to for joint account notifications. The ‘alternative notification schedules’ simply refer to alternative notification settings that may be made available to the consumer – i.e. the alternatives to the default. This could include turning off particular types of notifications, turning off all notifications, or for example, a statement containing all JA authorisation notifications over the course of a month provided to the consumer at the end of each month (i.e. an alternative frequency). Generally, the intention is to allow the standards to fill in the detail for JA notifications, and this will be an area we consult on in the coming weeks.
1149 Could you clarify/confirm the below understandings from the standards - 1. For a Banking API, The error list provided after every API definition is not an exhaustive list of errors, and we can return any error that fits well to the scenario from the list in Standards Errors section provided under high level standards. Or will DSB provide a list of valid errors for each end-point? 2. For all Security Endpoints except the CDR Arrangement Revoke endpoint, error response from the upstream normative standards apply instead of the Error Response Structure in the CDR Standards - High level standards. 3. Is it mandatory to return the Error Response Structure for errors which never reach our application, for e.g., scope/token validation errors returned from WAF/API gateway? The question is specific to the error response structure and not the response code. Question 1. For a Banking API, The error list provided after every API definition is not an exhaustive list of errors, and we can return any error that fits well to the scenario from the list in Standards Errors section provided under high level standards. Or will DSB provide a list of valid errors for each end-point? Answer 1: The list of errors provided against each API are mandatory for DHs to support. The Error Codes section of the data standards defines the standardised error codes. These error codes, unless otherwise specified, a SHOULDs meaning they are recommended to support where possible. Part of the feedback received during consultation was that not all error codes were as easy to implement under all scenarios (e.g. the error is handled by an upstream component of the architecture such as a WAF) and hence the requirement they are SHOULDs. Question 2. For all Security Endpoints except the CDR Arrangement Revoke endpoint, error response from the upstream normative standards apply instead of the Error Response Structure in the CDR Standards - High level standards. Answer 2: That is correct, unless the CDS makes explicit mention to errors. Question 3. Is it mandatory to return the Error Response Structure for errors which never reach our application, for e.g., scope/token validation errors returned from WAF/API gateway? The question is specific to the error response structure and not the response code. Answer 3: That depends on the error. If the error is a mandatory error the DH must respond in the format specified. If the error is not mandatory that is at the discretion of the data holder.

Useful Links

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