Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 3rd of March 2022

Jump to bottom
CDR API Stream edited this page Mar 3, 2022 · 6 revisions

CDR Implementation Call Banner

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.16.0 Published Link to change log here
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 2nd of March 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 16th of February 2022 View in browser here
DSB Newsletter 25th of February 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation
Action Article on Token Expiry and mutability Planned and in draft
Design Paper Design Paper: Consumer Data Right Rules and Standards for the Telecommunications Sector Link to DSB GitHub
Link to Treasury page

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
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - 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 submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1316 As per CDS specs previous months availability metric description say "A maximum of twelve entries is required if available." My understanding is that if previousMonths data is not available we don't have to include it in availability metrics response. For example, if we don't have data available before October 2021, our response will be as following:{ "currentMonth": 1.0, "previousMonths": [ 1.0, 0.98, 0.97 ]}Is my understanding correct? Yes, this is correct.
1321 The standards provide some clear guidelines around payload conventions and the ability to extend payloads with proprietary properties, but doesn't seem to explicitly define standards nor mention the required behaviour when it comes to additional payload properties that aren't intended as proprietary extensions.
For example, if a payload response includes the following CommonPhoneNumber object with an additional, undocumented property of 'carrier' that does not meet the extensibility convention:
{ "isPreferred": true, "purpose": "HOME", "countryCode": "string", "areaCode": string", "number": "string", "extension": "string", "fullNumber": "string", "carrier": "string"}
Is this payload considered valid?
What is the expected behaviour from both a DH and ADR point of view?
If it is deemed a valid object, then I would expect that the DH is OK to serve it up and ADRs should either use the additional property if they choose to or ignore it.
If it is deemed an invalid object, then I would expect the DH should treat it as a bug and rectify it, while ADRs should either ignore the additional property or reject the object as invalid.		 The purpose of including the extensibility standards was specifically to provide a mechanism to safely including additional fields.
Adding additional outside of these rules would not be considered valid so no, the schema presented would not be compliant. The reason for this is that there are many ways to create a client and the inclusion of arbitrary additional fields could easily break a client implementation depending on the choices they have made.
That said, there is no obligation on the ADR to reject the valid data if an additional field exists.
In this context I would concur with the expected behaviour for both DH and ADR that you propose. DH should treat is as a bug and ADR should ignore the field, use the field or throw an error at their discretion.
1349 in the Register old website there was a section on back off patterns and responsibility of each party in case the others are down. Has that been ported to the CDR spec or we should use the old website for this? There is a requirement that the data holder notifies the data recipient of the withdrawal of authorisation and to aid participants, the Register design specified backoff patterns as implementation guidance. Due to this categorisation, it was not transferred to the Consumer Data Standards.
However, the short and long-term approaches specified at https://consumerdatastandardsaustralia.github.io/register/#backoff-patterns are still relevant.
1362 Can you please confirm which Performance tier applies to Get Bulk Direct Debits and Get Direct Debits For Specific Accounts when the customer is present?
The table within the Performance Requirements section confirms that the "Large Payload" applies to these 2 endpoints for unattended calls. However, these 2 endpoints are not listed in the "Low Priority" tier when the customer is present.
Accordingly, can you please confirm whether the "Low Priority" tier or the "Large Payload" applies when a call is made to these 2 endpoints and the customer is present		 This appears to be a standards defect. We'll raise an issue on standards maintenance.
The sentence under Large Payload should be: 'Any calls to the following endpoints:' rather than 'Any Unattended calls to the following endpoints:'.
1376 Question: As part of a customer providing authorisation at the Data Holder's (DH) end for a given collection consent, is there any regulatory requirement for the DH to check if the customer has any existing active consent that could conflict with their current authorisation? There is no such obligation. In addition, concurrent consents are independent and additive. There is no situation I am aware of where two different consents would interact in any way let alone conflict.
1383 As an Energy sector DH, we are seeking clarification on whether we are compliant with CDR authentication standards, if, during the consumer authentication flow
- We present the consumer 'One Time Password' (OTP) as stated in the standards;
- And then present a second-factor authentication for our voluntary 2fa customers, who have requested 2fa in our digital channels.		 The DSB does not certify compliance of specific implementations so don't interpret my response in this way.
That said, the following statement in the standards applies in this context:
"The delivery mechanism for the OTP is at the discretion of the Data Holder but MUST align to existing and preferred channels for the customer and MUST NOT introduce unwarranted friction into the authentication process"
Adding an additional authentication mechanism (2FA in this case) would be additional friction. The correct approach would be to use the nominated 2FA mechanism to provide the OTP rather than giving two OTPs in two different channels.

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