-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 22nd of February 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 | Topic | Update |
---|---|---|
Standards | Version 1.29.0 | Published: 21st December 2023 Change log |
Standards | Version 1.29.1 is in the works as a patch release | Due to be released soon |
Maintenance | Maintenance Iteration 18 commenced on the 7th February 2024 |
Agenda Please reach out to [email protected] for an invitation |
DSB Newsletter | To subscribe to DSB Newsletter | Link here |
DSB Newsletter ⭐ | 16th of February 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 330 - UNSW Reports | Link to consultation |
Consultation | Decision Proposal 340 - Maintenance Iteration 18 | Link to consultation |
Consultation | Noting Paper 342 - Information Security Working Group | Link to consultation |
Survey | If you are a CDR stakeholder, we want to hear about your experience finding and using CDR guidance. The ACCC has released a survey for businesses and individuals who are holder or receivers of CDR data, or who provide services to these parties. This includes, for example, data holders, accredited persons, CDR representatives and third-party service providers. Your response will help us assess the effectiveness of CDR guidance and identify potential areas for improvement. | The survey is available on the ACCC website and will remain open until 25 March 2024. |
Provides a weekly update on the activities of each CDR stream and their work.
Organisation | Stream | Member |
---|---|---|
ACCC | Register and Accreditation Application Platform, Conformance Test Suite & Participant Tooling | Christian |
DSB | Consumer Experience | Michael |
DSB | Energy | Hemang |
DSB | Standards | James |
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 |
---|---|---|
2231 | We have a query in relation to the “PerformanceMetrics” schema for Get Metrics v5. The latest CDS release on Github, doesn’t show the category ‘authenticated’ for the schema (refer PerformanceMetricsV3 – Consumer Data Standards (consumerdatastandardsaustralia.github.io)), whereas the approved decision proposal #288 shows that in the example and also states that the split should be similar to ‘InvocationMetrics’ break-up. Hence, we wanted to double-check with you if the performanceMetrics should have the split for ‘authenticated’ as well. |
The performance metrics should align to the NFR tiers and therefore should not have an authenticated tier as authenticated calls are broken down into highPriority, lowPriority, etc. The sample in the decision doc is, unfortunately, erroneous due to a cut and paste error but the actual text of the decision is accurate, as are the standards themselves. |
2271 | We are in the process of implementing V5 and is facing some issues. For one particular scenario below, we are not able to capture the increments in the abandonment counts across all stages of the consent flow. Scenario: customer is idle in the session for more than 2 mins then closes their window or browser after that. Issue: the abandonment count is not incremented by 1 in the above scenario. We just want to ask the question if this scenario is supposed to be counted and reported in V5. If customer hits the "cancel" button or closes the window/browser within 2 minutes of becoming idle, that is captured. |
When a user leaves the flow idle (beyond the session timeout) or experiences another type technical timeout or error, or closes their browser or app, that must be recorded in the respective abandon metrics. The Get Metrics V5 abandonment by stages has been updated to reflect some of these scenarios. I hope that makes the expectation clearer, but let me know if you think I've misunderstood your scenario. |
2281 | As per implementation all a fortnight ago, please clarify whether Holders should be presenting links as urlencoded or not. We have two active incidents related to our presentation of encoding. | We have looked into this. Obviously the standards are silent on this topic so I went and looked at some of the normative and informative standards and still didn't find anything definitive. I even looked at JSONAPI.org and that was also unhelpful. In light of this my response would be that this is at the discretion of the Data Holder. The DSB can't reasonably make this ambiguity go away by providing guidance as there will be Data Holders with different interpretations. |
2282 | In the error metrics v4 and v5 should the error code 405 be recorded as an error since it is a method not found error? | Response code 405 would not have been recorded in the aggregated error metrics object in V3 because it is not a 'server-side' error. In Metrics v4 and v5, the aggregate object retains the same definition as v3 for continuity, but the "unauthenticated" and "authenticated" objects are now intended to capture all error codes by code, as indicated by the "500", "property1", "property2" fields in the example. That means "405", "404" etc. and all other error codes should be included in those sections (where the Standards page shows 'additionalProperties'). There is more detail in this article - https://cdr-support.zendesk.com/hc/en-us/articles/6461435303823-CDR-metrics-and-reporting-by-Data-Holders#Errors |
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.