ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 1st of December 2022
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
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed 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.
| Type | Topic | Update |
|---|---|---|
| End of Year | 1st of December 2022 8th of December 2022 15th of December 2022 Last Call for 2022! |
Thank you to everyone for a great year! |
| CDR Implementation Call 2023 | Commences 19th of January 2023 | Invitations to be updated and sent out |
| Standards | Version 1.20.0 Published on 3rd of November 2022 | Link to change log here |
| Standards | Version 1.21.0 is being prepared | ETA is mid December 2022 |
| Maintenance | Maintenance Iteration 13 change window concluded | Met 23rd of November 2022 and the agenda for the meet is here |
| Maintenance | Decision Proposal 272 - Maintenance Iteration 13 | Changes, meeting notes and updates for the iteration can be found here |
| Maintenance | Retrospective for MI13 to be held 14th of December 2022 | Invitations have been sent |
| Maintenance | Iteration 14 to Commence on 8th of February 2022 | Invitations to be sent |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | 3rd of November 2022 | View in browser here |
| DSB Newsletter | 25th of November 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 |
| Noting Paper | Noting Paper 255 - Approach to Telco Sector Standards | Link to consultation |
| Noting Paper | Noting Paper 258 - Independent Information Security Review | Link to consultation |
| Consultation | Decision Proposal 267- CX Standards Telco Data Language Feedback closed: 15th of September 2022 Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October. Reopened for feedback until the 9th of December 2022 |
Link to consultation |
| Consultation | Noting Paper 273 - Consent Review |
Feedback closes: 9th of December Link to consultation |
| Consultation | Decision Proposal 275 - Holistic Feedback on Telco Standards | No Close Date Link to consultation |
| Consultation | Noting Paper 276 - Proposed v5 Rules & Standards Impacts | No Close Date Link to consultation |
| Guidance | The ACCC has published guidance on the eligibility criteria for CDR consumers in the energy sector. | The guidance helps data holders assess whether a consumer is eligible for data sharing in CDR and considers the different account structures in the energy sector. It also provides guidance on a variety of example scenarios. |
| Feedback | If the CDR Community are able to provide feedback on this banking-related item from Maintenance Iteration 13: Specify if an Account is a joint account in the API response #513 | The DSB are looking for feedback by end of 9th of December 2022 |
Provides a weekly update on the activities of each of the CDR streams and their stream of work
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register | Emma Harvey |
| ACCC | CTS | Andrea Gibney |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking and Info Security | Mark Verstege |
| DSB | Technical Standards - Energy | Hemang Rathod |
| DSB | Technical Standards - Telecommunications | Brian Kirkpatrick |
| DSB | Technical Standards - Register | James Bligh |
| DSB | Engineering | Sumaya Hasan |
Java Script Holder SDK
A middleware solution is currently being developed by the DSB to address problems with repetitive programming tasks and help with API endpoints requirements. This package is a boilerplate implementation of these common requirements. It can be used in any NodeJS / ExpressJS application as middleware.
To find out more about the JS Holder SDK, please go to https://github.com/ConsumerDataStandardsAustralia/js-holder-sdk
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 |
|---|---|---|
| 1448 | Under Competition and Consumer (Consumer Data Right) Rules, section 3.2 Meaning of required consumer data and voluntary consumer data—energy sector it is stated that: (7) Despite subclause (2), for an account that is closed at a particular time, each of the following is not required consumer data: (a) CDR data held by AEMO, other than metering data; (b) CDR data held by a retailer, other than billing data; and (c) CDR data that is not excluded by paragraph (a) or (b), but relates to a transaction or event that occurred more than 2 years before that time. Qs1. in above para, 7(b), does 'billing data' refers to both - billing CDR Energy api & invoicing CDR Energy api Qs2. in above para, 7(c), tenure of 2 years is applicable for both billing & invoicing Qs3. in above para, 7(b), does 'metering data' refers to both - Service Point AEMO api & DER AEMO api |
the following article on Guidance for energy closed accounts will address your question on accounts closed at particular time. |
| 1801 | Seems like the format of the publicBaseUri in the energy/data-holders/brands/summary endpoint has changed? Attached is a screenshot, but as of the 8th of Nov Origin Energy and AGL now have different publicBaseUris from before. All other companies are still following the previous format. Also, both Origin and AGL have different Uri paths from each other, there seems to be no standard between the two. I couldn't find a recent change log regarding this update. Nor could I successfully use that baseUri for other endpoints, eg. energy/plans. The old base Uri however still works for Origin and AGL on the energy/plans endpoint. I know from a previous ticket regarding this endpoint that it's maintained by ACCC but I am trying to use these BaseUris as a foundation to access all other planID and plan details endpoints. These change have been a real cat thrown amongst the pigeons for my current development. |
This is due to a known issue which I've tried to summarise below. As per the rules, the designated data holder for energy PRD is AER and the Victorian agency (DELWP)(refer to the note in Subrule 2.3(1) of the rules). Consequently, all the PRD data and APIs are developed, published and maintained by AER. However, there is a known limitation for the base URI's available via this API. Specifically, a data holder (DH) can only have one public base URI. The public base URI is used for the PRD endpoints (i.e. Get Generic Plans and Get Generic Plan Detail) as well as the DH's Status and Outage APIs. The base URIs for energy PRD would continue to point to AER/EME until the time an energy retailer is onboarded onto the register to go live with CDR consumer data sharing. This would result in the AER/EME's public base URI for that retailer being replaced by the retailers own (e.g. https://cdr.energymadeeasy.gov.au/agl/ being replaced by https://public.cdr.agl.com.au/). The rules team are working on amendments to resolve this by requiring a proxy or redirect to be implemented by the energy DHs. You can read about it more in the noting paper available here - https://github.com/ConsumerDataStandardsAustralia/standards/issues/248 As a tactical solution, the following two alternative sources have been defined while the rules are being amended: - Option 1 (tactical): Energy PRD Base URI list published AER's website - https://www.aer.gov.au/consumers/energy-product-reference-data - Option 2 (tactical): datasources.json file of the product comparator demo/tool |
| 1803 | Just confirming that the old uri format for the endpoints discussed will be up to date with the most current PRD? |
Question: Thanks for the speedy reply. So it sounds like the PRD endpoints "brands/summary" etc. are still being maintained at the old URIs (https://cdr.energymadeeasy.gov.au/agl and https://cdr.energymadeeasy.gov.au/origin) is that right? Even as Origin and AGL release new plans and update old plans all of that information will still be reflected by using those older URIs? The same goes for other companies as they too make that transition? Answer: In short, yes. |
| 1811 | Q: Are Data Holder servers supposed to use certificates from the CDR CA (Certificate Authority)? Or can they use globally-trusted CAs? | A: For Data Holders, the CDR certificate is only to be used for MTLS endpoints where it secures communication to resources requiring authentication. Resource endpoints that do not require authentication must not use the CDR certificate; they use TLS only and should be secured by certificates issued by a well-known CA recognised by major browsers. For more details in the standards, see Transaction Security. |
Ticket 1803 Continued:
To summarise:| Energy Data Holders | PublicBaseUri for Status & Outage APIs | PublicBaseUri for PRD APIs |
|---|---|---|
| Retailers onboarded onto CDR register | Get data holder brand summary API | AER CDR pagedatasources.json file of Product Comparator Demo |
| Retailers not on CDR register | N/A | Get data holder brand summary APIAER CDR pagedatasources.json file of Product Comparator Demo |
Following up on the above ticket, just confirming that the old uri format for the endpoints discussed will be up to date with the most current PRD
That is correct. My suggestion would be to rely on the AER's list as they are ultimately the data holder and source of through for energy PRD information.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |