ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 9th of December 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
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 Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 9th Iteration Retrospective Survey
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 3rd of December 2021 View in browser here
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Link to consultation
Video [10] Decision Proposal 225 - narrated by Neale Morison (08/12/2021) Data Standards Body Youtube
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
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 - Energy Hemang Rathod
DSB Technical Standards - Banking & Engineering Mark Verstege

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
1217 Previous decision proposal released on errors had several error codes regrading 401 and 403 http status codes. In the new error standard (https://consumerdatastandardsaustralia.github.io/standards/#error-codes), there is nothing related to 401 and 403 status codes except a few ADR status and consent status related 403 standard error codes. In situations like invoking an API with insufficient permission (scopes), previously we sent a 403 forbidden with "Resource Forbidden" code. Since the specification does not include those kinds of error codes anymore, is it OK to use 4xx general error code during those scenarios? If the error behaviour is described by the upstream normative standard, that takes precedence. 401 and 403 errors are still permitted. In your situation where the authorised scopes do not permit the client calling a particular endpoint (insufficient permissions), you should refer to the oAuth specification for the correct error code and error response.
1227 **Scenario ** A member wants to share the CDR data with the ADR, but due to member being flagged as fraud or vulnerable, the member won't be able to proceed with the data sharing at the authentication stage and will thrown an error. This the first time member using this service, hence no active consent is there. Question What error code to be displayed in such a scenario when an membership is flagged as fraud or vulnerable? Is it 403 forbidden or 422 - Unprocessable Entity On the CDS website on the Exemptions To Protect Service we have 403 that mention "If the data holder identifies a situation where there is the potential for physical or financial harm or abuse (this should result in http error 403 Forbidden being returned" Link: https://consumerdatastandardsaustralia.github.io/standards/#exemptions-to-protect-service If it 422 - Unprocessable Entity, then what need to be displayed in the "Title and Detail" in the error code structure" this is at the discretion of the Data Holder. During consultation, Data Holders told us that for sensitive situations like fraud or consumer vulnerability, the disclosure of too much information could lead to harm. It is up to the Data Holder to determine what data they provide in the error description. It is up to the Holder to determine the appropriate error code in these situations. Both 403 or 422 would be acceptable as well as 404 if the resource being requested is in the URL path. Unavailable Banking Account and Invalid Banking Account provide broad and generic error handling if you seek to respond with a 404 or 422.
1233 Is there any eligibility requirements on nominated representatives (like age, IB access etc which applies to CDR consumers)? Or does data holder simply need to confirm they are authorised to act for the non-individual? Recent amendments to the CDR rules have clarified that a nominated representative must be an individual aged 18 years of age or older (rule 1.13(1)(c)(i) and (d)(i)). Otherwise, while in practice we expect most nominated representatives will be employees of the business consumer, the CDR rules do not restrict the type of person that can be a ‘nominated representative’ for a business consumer. Rather, the CDR rules relating to nominating representatives are intended to allow data holders to leverage their existing systems and processes for dealing with their business consumers. For example, a data holder may have existing arrangements in place with their business consumers which identifies the individual/s that are authorised to act as agents for the business and make decisions like which individuals can transact on behalf of the business for particular business accounts. Note that we are in the process of developing guidance for data holders on implementing the CDR for business consumers and hope to publish these on Zendesk in the new year.

Useful Links

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