ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 30th of May 2024
When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 5 min will be al lowed for participants to join the call.
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.
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.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
⭐ indicates change from last week.
| Type | Updated | Links |
|---|---|---|
| Standards | Version 1.30.0 | Published: 24th of April 2024 Change log |
| Maintenance | Iteration 19 underway | You can sign up here. Look for the Maintenance Iteration 19 Series. |
| Maintenance | Iteration 19 Schedule 1/05/2024 Consultation 15/05/2024 Consultation and new issue checkpoint 29/05/2024 Proposal Checkpoint 12/06/2024 Approvals and Documentation |
Agendas and Meeting Minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 24th of May 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Noting Paper 346 - Standards Assessment Framework |
Feedback closes: 12th June 2024 Link to consultation |
| Engineering | Test Data CLI: The latest release of the relevant Github Repository includes an updated README file. | - |
| Engineering | JS Holder SDK : The latest release of the relevant Github Repository includes an updated README file. | - |
| Engineering | JS Holder SDK (Demo): The latest release of the relevant Github Repository includes an updated README file. | - |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| DSB | Engineering | Sumaya |
None this week.
Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
| Ticket # | Question | Answer |
|---|---|---|
| 2322 | - Statement 3 has now clarified that paragraph (3)(h) now applies on and after 1 July 2024. However, (3)(h) denotes that paragraph 3h dictated by when a data holder receives a consumer data request from an accredited person and not when the request to disclose consumer data is first authorised or amended. Does this mean that the consent history view is required for all consents where data sharing is active as at 1 July 2024 or is the intent for it to only apply for any new authorisations to share data (or amendments) following 1 July 2024? | Regarding your question relating to the 1 July obligation date, the ACCC has stated that they consider that rule 1.15(3)(h) only applies to amendments that occur on or after 1 July 2024. This means data holders are not required to present details of amendments to authorisations prior to this date but may voluntarily do so. We encourage data holders who are concerned about their compliance to contact the ACCC Compliance team directly at [email protected] to discuss the issue. |
| 2346 | As per the recent CX guidelines, we need to capture the consent amendment history on the consent dashboard (refer: Authorisations (cds.gov.au)). We wanted to check if there are any guidelines on how long the consent amendment history should be maintained to display on the dashboard. For example, if a customer keeps amending a consent for 10 years, then do we need to provide the amendment history for 10 years? Or, can we limit it to as per the recordkeeping requirements in the legislation (refer 9.3 (5)) | As you have noted, an accredited person’s consumer dashboard must contain details of each consent, including details of each amendment (if any) that has been made to the consent (see rule 1.14(3)(i)). Similarly, a data holder’s dashboard is required to contain information for each authorisation, including details of each amendment that has been made to the authorisation (see rule 1.15(3)(h)). Section 4.8 of the Compliance Guide for data holders in the banking sector provides that information on a data holder’s dashboard must contain details of the authorisation within the past six years. Therefore, we consider that for accredited persons, the consumer dashboard should also contain relevant details of each consent within the past six years, including any amendments to the consent within that period. As you note, the six-year time period for displaying relevant details of authorisations and consents aligns with the record-keeping obligations for data holders and accredited data recipients specified in Rule 9.3. |
| 2364 Part 1 | The ACCC have raised an incident on us and requested that we supply previousDays in hourly elements (ie same as currentDay). But the standards clearly request previousDays in daily elements. From the highPriority section (by way of example), currentDay refers to "Each element represents a 1 hour period starting from 12am-1am", whereas previousDays refers to "The first element indicates yesterday and so on. A maximum of seven entries is required if available." The same text is used in each performance tier. From our perspective this is unambiguously clear. | The Standards documentation doesn't render that level of detail for these nested array elements, but the detail is apparent in the Admin OpenAPI Specification file found here - https://consumerdatastandardsaustralia.github.io/standards/index.html#admin-apis Line 16 and 18 in the snippet from the spec. below, represent the details required for the array elements for the High Priority performance tier, for example. The previousDays array mimics the currentDay hourly style for each of the previous days. Where the documentation displays [array] for previousDays, this is the array of days (line 16). The value for each day is an array of hourly values (line 18). |
| 2364 Part 2 | I've located the Open API Specification (which I'd never seen before). I do, however, completely disagree with your comment that "The Standards documentation doesn't render that level of detail for these nested array elements." The previousDays state that "The first element indicates yesterday and so on. A maximum of seven entries is required if available" If we were to do as you are suggesting (as per the Open API Specification) we would have 168 entries not seven. It looks to this (possibly ignorant) observer like a copy and paste error in the Open API Spec. Presumably the standards documentation is superordinate to the Open API Spec? What is the status of the Open API Spec exactly? | Yes, there are seven entries for previousDays, but the value of each entry is an array of 24 (hourly) values, as demonstrated by the [array] value. As the previousDays values are an array of arrays, the 168 entries you noted does equate to 7 array items (the outside array of previous days), and each day item is another array of 24 entries (an array of hours for that day). The Non-normative Examples area may demonstrate the structure more clearly. A further example demonstrating this is shown in Decision 288 which was the source of these new values being specified - https://github.com/ConsumerDataStandardsAustralia/standards/issues/288#issuecomment-1599976783 The previousDays example near the top of page 11 shows an array of three days, containing arrays of hourly values (most with a "1" for each hour). As for the OpenAPI specs., the Standards endpoint documentation sections are a HTML rendering of the Open API specifications provided at the top of each section, so neither is really subordinate. Some parts of the Standards, where endpoints are not defined, are not based on Open API specs.; such as the InfoSec, CX and NFR sections. As noted above, we will see what we can do to make these array structures clearer in the documentation. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |