ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14th of December 2023
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 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.
⭐ indicates change from last week.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.28.0 | Published: 10th November 2023 Change log |
| Standards | Version 1.29.0 will contain Maintenance Iteration 17 Changes and others | Team is staging the changes. Week starting 18th of December 2023 . |
| Maintenance | Maintenance Iteration 17 Working Groups Completed | All agendas and meeting minutes |
| Maintenance | Maintenance Iteration 18 planned to commence February 2024 | Invitations to come |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 8th of December 2023 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 280: The CX of Authentication Uplift | No Close Date Link to consultation |
| Consultation | Noting Paper 307 - LCCD Consultation Approach | No Close Date Link to consultation Video |
| Consultation | Noting Paper 308 - Categories of Standards | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Decision Proposal 335 - NFR Working Group | Link to consultation |
| Consultation | Decision Proposal 338 - Updates to Banking Products and Accounts - Binding Standards | Feedback Closes: 15th of December 2023 Link to consultation |
| Guidance ⭐ | The ACCC and the OAIC have jointly published new guidance to assist CDR representative principals understand what steps they should take to ensure their CDR representatives comply with their CDR representative arrangements. The Guidance for CDR representative principals on ensuring compliance of their CDR representatives is available now on the CDR website. | Guidance for CDR representative principals on ensuring compliance of their CDR representatives |
| Product Comparator (Demo) ⭐ | A new enhancement has been published to highlight the Status and Outages APIs published by the AEMO. | Product Comparator Demo Link |
| JSON Schema Tools ⭐ | The Github Repo dsb-schema-tools has been updated to align to the latest CDS version (1.28.0). | Link: dsb-schema-tools) |
| Thank you! | This week is the last CDR Implementation Call for 2023 Thank you to everyone who has made this regular channel of communication such a success for 2023 |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Eva |
| ACCC | Conformance Test Suite & Participant Tooling | Christian |
| DSB | Consumer Experience | Michael |
| DSB | Engineering | Sumaya |
| DSB | Energy | Hemang |
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 |
|---|---|---|
| 2114 Part 1 | Is there an easy way I can see the changes between schema versions? For example, I'm trying to find the differences between EnergyAccountDetailV2 and EnergyAccountDetailV3, though it would be good to be able to compare any schema version. Also, is it possible for a change in a property description to bump up the schema version number? |
You can compare EnergyAccountDetailV3 with EnergyAccountDetailV2 by looking at the v2 version here - https://consumerdatastandardsaustralia.github.io/standards/includes/obsolete/get-energy-account-detail-v2.html#tocSenergyaccountdetailv2. The link for it is provided at the start of the API. You can also see what has changed in the version delta tab by looking up the achieves of when the change was introduced. In this case it would be https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.24.0/#energy-apis With regards to property description change, it would typically not result in version update unless it results in any material change on how that property is implemented or consumed or interpreted. |
| 2114 Part 2 | I ended up pasting both V2 and V3 into excel and then comparing every single column and the change seems to be gasContract and electricityContract changing from EnergyPlanContract to EnergyPlanContractV2. Is that the reason for the change to V3? Surely there’s a better way to see the difference? | Another way would be to compare the versions in github. In this instance, for e.g., you can compare current version (1.28.0) to version 1.23.0 (prior to when EnergyAccountDetailV3 was introduced) and check out the difference in cds_energy.json file. For context, cds_energy.json is the swagger file where all the end points and payloads/schema structure for the Energy sector is defined. Here's an example link - https://github.com/ConsumerDataStandardsAustralia/standards/compare/v1.23.0…v1.28.0 |
| 2175 | Do we have a ticket or reference that supports the following change ? “it is now mandatory to include the scope, response_type, client_id, and redirect_uri parameters when making a call to the authorization endpoint, regardless of whether it is for an authorization code or hybrid flow.” But specification still shows: Authorise - FAPI 1.0 Final Phase 3 Obligation ## This is used by the ADR in the subsequent authorisation request as follows ## (this example uses PAR RFC 9126 and Authorization Code Flow): GET /authorise?client_id=s6BhdRkqt3& request_uri=urn%3Adata.holder.com.au%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 Host: data.holder.com.au |
The relevant change request can be found here: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/288 |
| 2172 | We have some large business customers that are eligible for CDR which are on tariff where we pass through the network charges to them. There are a significant number of network charges (also attached) and I'm not sure how well they will map to the existing energy schemas. I'd like to confirm if these network charges are in scope for Get Energy Account Detail api? |
With regards to the Get Energy Account Detail API, the intent of this endpoint is to provide detail about the plan the customer has signed up for include all rates/charges applicable as part of the agreed plan. This would also include network charges and should be shared. In the rules its noted a product specific data as below:  We can reach out to the rules team if are any rules related clarification is required. |
| 2137 | When a consent is amended: An existing consent is revoked, and A new consent with the same cdrarrangementid is created by the data holder. During step 1, is it necessary for the data holder to send a revoke request to the ADR? We believe that sending a revocation request to an ADR would signal to the ADR that the consent has been withdrawn by the customer. Consequently, any CDR data collected on behalf of the customer would be marked as redundant. In other words, it must either be deleted or deidentified. This aligns with the customer's intent when amending or renewing their CDR consent prior to its expiry. |
Thank you for your enquiry, we have consulted with the DSB in preparing the below response. From a Rules perspective there is no requirement for a data holder to send a revoke request to the ADR when a consumer amends an existing consent. The need for a revocation of a consent and a corresponding consent created with the same cdrarrangementid through the process you have outlined is due to technical constraints, rather than legal requirements. Under the CDR Rules, the ADR will be aware that an amended authorisation is being sought as they have either sent a rule 4.18C or rule 4.20S notice to the data holder, and the Rules then require the data holder to invite the CDR consumer to amend the related authorisation accordingly. We consider that from a consumer’s perspective it should look like a continuation of their consent with their authorised amendments. Therefore, only data that has become redundant as a result of the consumer’s amendment to their consent (i.e. any data that is no longer reasonably needed to provide the consumer with the request goods or services under the amended consent) will need to be deleted or de-identified. |
| 2197 | I am having issues with a credit card product providing my data to money management app. When I link my credit card through the money management app, the link does not complete, but I receive an email from credit card product saying the data sharing is active. I have tried to enquire numerous times with credit card product support and they are giving me vague answers and the run around, saying they are investigating if I'm an eligible consumer? Why would I not be eligible? I'm over 18, an individual, and have an open account... this is the criteria according as I am reading it. Some guidance and clarity on this would be appreciated as I understand it's a known recurring issue with this credit card product. |
Under the CDR Rules, data holders are required to enable sharing of required consumer data for eligible CDR consumers. For the banking sector, a consumer will be considered an ‘eligible CDR consumer’ if: - they are an account holder or secondary user for an open account with the data holder; - they can make transactions on that account; - that account is set up so it can be accessed online; and they are: - an individual who is 18 years of age or over, - a person who is not an individual (for example, a corporation), or - a partner in a partnership. The eligibility criteria for a consumer in the banking sector is set out in rule 1.10B and clause 2.1 of Schedule 3 to the CDR Rules. We encourage you to liaise further with the bank that has issued your credit card if you require further information about your eligibility to share data under the CDR. If you have repeatedly tried to seek an answer from the bank that issued your credit card and you’re still not satisfied with their response, you can make a CDR complaint to that bank. If they don’t respond to your complaint after 30 days or you are not happy with their response you can lodge a complaint with the Office of the Australian Information Commissioner or the Australian Financial Complaints Authority. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |