ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 2nd of February 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

Acknowledgement of Country

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.

House Keeping

Recording

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.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.22.0 published 23rd of December 2022	Version 1.22.0 Change Log Release video 1.22.0
Maintenance	Iteration 14 to commence on 8th of February 2022	Invitations sent out.
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	5th of December 2022	View in browser here
DSB Newsletter	13th of January 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language	Feedback extended with an end date to be determined pending the making of the telco rules. 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
Design Paper	Design Paper: Consumer Data Right Rules and Standards for the Non-Bank Lending Sector	Feedback closed 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	Feedback closes: 10th of February 2023 (extended) Link to consultation
Consultation	Decision Proposal 287 - Energy C&I Consumers	Feedback closes: 17th of February 2023 Link to consultation
Consultation	Noting Paper 290 - Binding Statement	Feedback closes: 3rd of February 2023 Link to consultation
Workshop	7th of March 2023 Action Initiation Workshop 01	Registration for Workshop

CDR Stream Updates

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 & Infosec	Mark Verstege
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Register	James Bligh
DSB	Engineering	Sumaya Hasan

Presentation

Noting Paper 291

Presenter: Mark Verstege Link: Noting Paper 291 on GitHub

Noting paper 291 outlines consultation on simplified Payments Initiation workshop to be help on Tuesday 7th of March. This workshop seeks to understand existing industry payment initiation processes. It is the first in a planned series of workshops to elicit input into how actions are currently initiated by industry participants across sectors and a variety of action initiation use cases. The noting paper covers over possible workshop focus areas with feedback requested from participants in prioritisation of subsequent workshops.

Q&A

Questions on Notice

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.

Answer provided

Ticket #	Question	Answer
1833	Scope for Energy Invoice: If I wish to retrieve Invoice information for an Energy Account (e.g. using https://consumerdatastandardsaustralia.github.io/standards/#get-invoices-for-account), when we ask the consumer to consent to the scopes, which one of the Energy Data Language standards covers this data? I can see Invoice number mentioned in "Billing payments and history" - is it then implied (and acceptable) that the consumer has consented for the more detailed Invoice data? And/or because it's retrieved for a specific account that has been consented to (i.e. consent for "Account and plan details"), again is that sufficient?	If you wish to retrieve the Invoice information, you would present the consumer with the data cluster that maps to the scope required to access the Invoice API. Specifically, you would present the consumer the "Billing payments and history" data cluster to consent to, and the APIs that require energy:accounts.basic:read scope can be used to get the data. Note that some of the Invoice APIs require an account id as an input, which can be acquired via the Get Energy Accounts API. This would mean that consent for be "Accounts and plans" cluster is also required. What scope an API requires is mentioned in the description of the API. An example below for the energy invoice APIs: https://consumerdatastandardsaustralia.github.io/standards/#get-energy-accounts A scope may include one or more APIs. If the consumer has consented to "Billing payments and history" cluster, the APIs that require the mapped scope energy:billing:read can be used, which includes the invoice APIs. An example/guide on how the screens/UI can be presented to the consumer for consent can be found in the CX Guidelines. If you are only requesting invoice data and the permissions cover more than what's required, you may choose to follow the UI below: https://d61cds.notion.site/Collection-and-use-consents-fcf5e47455274d26b028d218b22f017a
1834	From Consent Sequence Diagrams: I found this diagram very useful but there is one thing that might not be 100% correct. In the "preparatory sequence" section, as illustrated in the diagram, the Data Holder should be able to cache ADR's JWKs beforehand. But as stated in CDS( Security Endpoints – Consumer Data Standards (consumerdatastandardsaustralia.github.io)), Data Holder should only be able to get ADR's JWKs in SSA during the dynamic client registration. And I checked that ADR's JWKs URI couldn't be retrieved from participant endpoints provided by register either.	There are two different concepts at play here: - The URI that the ADR makes available or obtain the keys (ie. the JWKS end point) - The actual keys that can be obtained from the JWKS end point (ie. the keys themselves) When the standards talk about the JWKS being in the SSA it is referring to the URI (ie. the location to call to get the keys). The diagram, however, is talking about caching the keys obtained from that end point (ie. the actual key set) so that the keys can be used multiple times without having to continually hammer the ADR's JWKS end point.
1840	Can you please confirm if the following 2 scenarios are correct? Scenario 1: If an account holder on a Joint account does not meet eligibility criteria, a Secondary User (who has a Secondary User instruction) cannot share data on that joint account as the account is unavailable for sharing. Scenario 2: If an account holder on an individual personal account / sole trader account does not meet eligibility criteria, a Secondary User (who has a Secondary User instruction) can share data on that individual personal account / sole trader account as the account is available for sharing. Are those two scenarios correct?	Thank you for your enquiry. With regard to scenario 1, in order to be able to share joint account data, all joint account holders must be 'eligible' consumers in their own right. This means, for example, that if a relevant joint account holder does not have online access to any of their accounts, then the joint account is not eligible for data sharing by any of the joint account holders. Therefore, you are correct - if a joint account holder does not meet eligibility criteria, then that account is unavailable for CDR data sharing. According to the CX Standards, the joint account can still appear in the authorisation flow to mitigate confusion for consumers, but the account cannot be selected and is an 'unavailable account' because at least one joint account holder has ceased to be an eligible CDR consumer. Similarly for scenario 2, if an account holder does not meet CDR eligibility criteria then that account is not available for CDR data sharing, including for a secondary user. Therefore a secondary user cannot share data from an account for which the account holder is no longer an eligible CDR consumer.