ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 5 December 2024
When: Weekly every Thursday at 3pm-4:30pm AEST
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 and present, 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.32.0 | Published: 21st of October 2024 Change log |
| Standards | Version 1.33.0 | Coming soon |
| Maintenance | Iteration 22 to commence in February 2025 | Registration open |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 29 November 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 345 - Data Standards Body Capability, Consultation Processes and Operating Model | Link to consultation |
| Consultation | Noting Paper 352 - Cost and change considerations | Link to consultation |
| Consultation | Noting Paper 355 - Deceptive Patterns Independent Health Check | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 357 - LCCD Benefit Workshop Summary | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 359 - Deceptive Patterns Health Check - Next Steps | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 360 - Chair response letter statement of intent | Link to consultation |
| Consultation | Consumer Data Right Rules – non-bank lending and banking data scope | Treasury page for the consultation |
| End of Year | Calls remaining in 2024: - - - - |
Return on 16 January 2025 |
| News | New Data Standards Body website New features: - news and announcements - banner for greater focus on items - inclusion of Digital ID work - bring all of data standards body work into one place |
View dsb.gov.au |
| CX | New domain and link for the Consumer Experience Guidelines: https://cx.dsb.gov.au/ | Note redirects will be put in place for the existing domain cx.cds.gov.au soon |
| Thank you | A big thank you to everyone for their part in the journey that was 2024 for the CDR Implementation Call. This call is only as successful as the Community it is a part of: and you've made that awesome. While this year has been quite the roller coaster: 2025 looks to have some exciting items on the horizon. | Enjoy the festive season |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| DSB | Consumer Experience | Michael |
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 |
|---|---|---|
| 2456 | In the CDS Specification, under client registration section [1], the SSA definition used by the CDR Register has been given. There are few data fields marked as not modifiable under that. Our current understanding is that the CDR Register ensures those fields are not modified when an SSA is issued to update an existing Software product. We need to get the following clarified regarding the above scenario. 1) Should a Data Holder compare the existing SSA and the new SSA sent in the DCR PUT request to check whether the unmodifiable fields are modified, and return an error. 2) If returning an error is required, what is the error_code that can be used? 4) The fields iat, exp, and jti are marked as not modifiable in the specification. As per our understanding, those fields can change when generating a new SSA. If returning an error is required for the above scenario, should these fields also be part of the validation. 3) If returning an error is not required, is it acceptable to ignore the fields marked as unmodifiable and accept the DCR PUT request as a valid request? [1] - https://consumerdatastandardsaustralia.github.io/standards/#client-registration |
Question 1: Should a Data Holder compare the existing SSA and the new SSA sent in the DCR PUT request to check whether the unmodifiable fields are modified, and return an error. Answer 1: Yes, according to the current Standards, but this may change as the DSB and ACCC review those details to address ecosystem expectations. Please refer to this issue for details - #679 - Update SSA specification. Question 2: If returning an error is required, what is the error_code that can be used? Answer 2: The Data Standards do not override the upstream specification in this respect - 3.2.2 Client Registration Error Response A non-normative example could be: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "error": "invalid_software_statement", "error_description": "The provided software statement contains updated values for fields that are not classified as modifiable." } Question 4: The fields iat, exp, and jti are marked as not modifiable in the specification. As per our understanding, those fields can change when generating a new SSA. If returning an error is required for the above scenario, should these fields also be part of the validation. Answer 4: Yes, according to the current Standards, but this may change as the DSB and ACCC review those details to address ecosystem expectations. Please refer to this issue for details - #679 - Update SSA specification. Question 3: If returning an error is not required, is it acceptable to ignore the fields marked as unmodifiable and accept the DCR PUT request as a valid request? Answer 3: An error may currently be expected, but as noted, this is under review. Accepting modifiable fields while silently ignoring 'not-modifiable' fields may produce unexpected results for clients. |
| 2461 | In the CDS Specification, under client registration section [1], the SSA definition used by the CDR Register has been given. There are few data fields marked as not modifiable under that. Our current understanding is that the CDR Register ensures those fields are not modified when an SSA is issued to update an existing Software product. Query#1: 1) Should a Data Holder compare the existing SSA and the new SSA sent in the DCR PUT request to check whether the unmodifiable fields are modified, and return an error. 2) If returning an error is required, what is the error_code that can be used? Query#2: The fields iat, exp, and jti are marked as not modifiable in the specification. As per our understanding, those fields can change when generating a new SSA. If returning an error is required for the above scenario, should these fields also be part of the validation. If returning an error is not required, is it acceptable to ignore the fields marked as unmodifiable and accept the DCR PUT request as a valid request? [1] - https://consumerdatastandardsaustralia.github.io/standards/#client-registration |
Query#1: Query 1.1: Should a Data Holder compare the existing SSA and the new SSA sent in the DCR PUT request to check whether the unmodifiable fields are modified, and return an error. Answer 1.1: Yes, according to the current Standards, but this may change as the DSB and ACCC review those details to address ecosystem expectations. Please refer to this issue for details - #679 - Update SSA specification. Query 1.2: If returning an error is required, what is the error_code that can be used? Answer 1.2: The Data Standards do not override the upstream specification in this respect - 3.2.2 Client Registration Error Response A non-normative example could be: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "error": "invalid_software_statement", "error_description": "The provided software statement contains updated values for fields that are not classified as modifiable." } Query#2: Query 2.1: The fields iat, exp, and jti are marked as not modifiable in the specification. As per our understanding, those fields can change when generating a new SSA. If returning an error is required for the above scenario, should these fields also be part of the validation. Answer 2.1: Yes, according to the current Standards, but this may change as the DSB and ACCC review those details to address ecosystem expectations. Please refer to this issue for details - #679 - Update SSA specification. Query 2.2: If returning an error is not required, is it acceptable to ignore the fields marked as unmodifiable and accept the DCR PUT request as a valid request? Answer 2.2: An error may currently be expected, but as noted, this is under review. Accepting modifiable fields while silently ignoring 'not-modifiable' fields may produce unexpected results for clients. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |