ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 21st of September 2023
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, 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.26.0 | Published: 24th August 2023 Change log |
| Maintenance ⭐ | Maintenance Iteration 17 | Commenced on the 20th of September 2023 |
| Maintenance | Maintenance Iteration 17 | All agendas and meeting minutes |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | 1st September 2023 | View in browser here |
| DSB Newsletter ⭐ | 15th September 2023 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 276 - Proposed v5 Rules & Standards Impacts | No Close Date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | 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 | Decision Proposal 317 - ‘Buy Now, Pay Later’ Product and Account Detail | 6 October 2023 Link to consultation |
| Consultation | Design Paper: Consumer Data Right Consent Review | 6 October 2023 Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Engineering | Engineering Update Frist Edition September 2023 |
Link to online |
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 | Christian |
| ACCC | Compliance | Seamus |
| 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 |
|---|---|---|
| 2019 | For C&I, there are some Emissions & Renewable Energy (E & RE) charges related to State and Federal environmental schemes (such as LRET, SRES, PDRS, VEEC etc.) which aim to encourage the additional generation of electricity from sustainable and renewable sources. Charges for these schemes are calculated based on a Certificate Price, and are itemised in C&I contract packs as "$/Certificate": Query1. The current DSB specs does not seem to have provision for passing "Certificate" as unit of measurement (from given enum list of measureUnit field under EnergyPlanTariffPeriod -> rateBlockUType (for both singleRate & timeOfUseRates), Request DSB to advise - how $/Certificate can managed/passed in the API for such government scheme charges. Query2. Considering above query for a specific "measureUnit" value in the given enums is to be accessed / confirmed by DSB, in the interim is the below workaround deemed ok, please advise - Pass prices in the “unitPrice” field of EnergyPlanTariffPeriod API in |
Having looked at some examples for E & RE (LSGC and SREC), it seems the certificates are per megawatt hour (MWh) which can be converted to KWH. This might be the easiest way to provide the rates in a standards compliant manner along with noting it in the description field. Anther option to could be to add the MHw as a value in the measureUnit ENUM, but this would require a standards change. Best way for this would be if you could raise a change request for this issue in standards maintenance so it can be consulted on with other retailers and addressed with their feedback. |
| 2089 | For a large retailer, what's the compliance obligation date for ATO (Authority to operate) related requirements, i.e. Power of Attorney, Court Appointed, Authority to Act, State Trustee? Is it November 1st 2023 or 1st May 2024 with 1st November 2023 being the obligation date for non-complex requests and 1st May 2024 for complex requests? Please advise. | Thank you for your question. A complex request means a consumer data request that: (a) is made on behalf of a large customer; or (b) is made on behalf of a secondary user; or (c) relates to a joint account or a partnership account. The CDR Rules do not contain any specific rules related to the arrangements mentioned in your question, and we are not able to provide compliance advice tailored to these scenarios. However, we have developed guidance on powers of attorney which may assist (available here: https://www.cdr.gov.au/guides/powers-attorney-and-consumer-data-right). Relevantly, an attorney acting under a power of attorney on behalf of a CDR consumer may: make a decision, be asked to do a certain thing, or receive a notification or information, where doing so is within the actual or apparent authority of the attorney set out in the power of attorney document. Where a person is able to act on behalf of a CDR consumer for CDR purposes under a legal arrangement, whether or not a consumer data request made under the arrangement will be considered a complex request may depend on whether the CDR consumer for the consumer data request falls into one of the categories noted above. |
| 2108 | Incorrect Non-Normative Example for code_challenge_methods_supported We encountered an issue with the "code_challenge_methods_supported" data holder metadata element. Where a couple of data holders are returning this element as below: "code_challenge_methods_supported": "S256" (probably referred to and implemented as per the non-normative example) And as per the specification definition, it's supposed to be a JSON array: "code_challenge_methods_supported: JSON array containing a list of [PKCE (RFC7636)] code challenge methods supported" The same has been reported today in the ACCC & DSB |
CDR Implementation Call (14-Sep-2023). As per RFC : https://datatracker.ietf.org/doc/html/rfc8414 code_challenge_methods_supported OPTIONAL. JSON array containing a list of Proof Key for Code Exchange (PKCE) [RFC7636] code challenge methods supported by this authorization server. Code challenge method values are used in the "code_challenge_method" parameter defined in Section 4.3 of [RFC7636]. The valid code challenge method values are those registered in the IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters]. If omitted, the authorization server does not support PKCE. |
| 2110 | Clarification of the error metrics requirement of DP288 and Get Metrics We would like to request clarification of the error metrics requirement of Decision 288 and Get Metrics. The Decision document has a sample data payload in the PDF document with 4xx and 5xx errors being reported. However, based on the description in current Get Metrics V4 specifications, specifically the ErrorMetricsV2, should DH only consider 5xx errors (as per today)? – “Number of calls resulting in error due to server execution over time” as per specifications There is an existing post (https://cdr-support.zendesk.com/hc/en-us/articles/6461435303823-CDR-metrics-and-reporting-by-Data-Holders#Errors) that qualifies that “Status code 4xx series responses should be:… Excluded from the 'errors' property of Get Metrics”. |
The description of the 500 field is as follows: Number of errors for HTTP error code 500. Note that this field is an example of a single entry due to the lack of OAS support for the JSON Schema patternProperties syntax. See the additionalProperties field in this schema for the generic property structure for error code counts I have added bolding for emphasis. The bolded section outlines that the patternProperties structure in OAS is used to describe a key/value pair pattern in this payload structure. The OAS to markdown conversion tool we currently use does not accommodate this well which is why we have included the additional detail in this description. All HTTP error counts should be reported in the ErrorMetricsV2 model in response to v4 or v5 Get Metrics invocation. |
| 2111 | Suggestion: Guidance around use of status and outages We uses data from the publicly available outage APIs published by each banking data holder to identify current or future disruptions to service and advise our customers ahead of this. It would help us to minimize any disruptions to service if: 1. We had more detail about which services may be impacted, for example consent flows or specific APIs or data sharing for certain customer groups or similar. Currently a typical statement in the explanation field might be "We will perform scheduled maintenance." with a duration hours on a certain date. There is rarely any detail which makes it harder for our clients to plan for disruptions. 2. There was more specific timing information - some providers schedule outages as long as 48hrs even if the actual period of disruption is much smaller. 3. There was more lead time for outages - sometimes the API is only updated days before a significant event. I'm sure that there may be balancing concerns, and the public nature of the APIs may limit the level of information that can be disclosed, but collaborating on some guidelines around the outage (and status API) could make them a more useful asset. Separately to the above it'd be great if data holders could communicate information about their release plans - this is done through confluence in the UK and all data holders communicate when they are moving to new standards versions - in our case this would be implementing against future dated obligations. |
This looks more like a request for change. If it is then it should be a CR raised via standards maintenance repository rather than as a support portal query. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |