ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 18th of May 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

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

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.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Maintenance	Iteration 15 met on 17th of May 2023	See the agenda
Maintenance	Iteration Candidates nominated!	List of candidates on the MI5 Project Board
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	24th of April 2023	View in browser here
DSB Newsletter	12th of May 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
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	UPDATE: See NP296 for continuation of consultation
Consultation	Decision Proposal 288 - Non-Functional Requirements Revision	Feedback closes: 19th of May 2023 Link to consultation
Consultation	Decision Proposal 302 - Telco Draft Feedback Cycle 2	No Close Date Link to consultation

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	Register	Eva
ACCC	CTS	Seamus
ACCC	Regulatory Guidance	Catherine
DSB	CX Standards	Amy
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Register	James
DSB	Technical Standards - Maintenance Iteration 15	Brian

Presentation

None planned for this week.

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
1971	I'm interested to understand what timelines are being worked towards for the non-bank lender industry. Could you please indicate what activities you expect in FY24?	Thank you for your enquiry. There is a Framework Design and Strategy Forum being held on Tuesday 16 May, which will give an indication of CDR consultations moving forward. If you would like to add your colleagues to the invitation list, please email [email protected]. We expect there will be consultation about the non-bank lending expansion this year.
1975	Our interpretation of this change is that our current solution remains complaint and no change is required from us post FAPI phase 3. Our current solution as part of FAPI phase 3 as below: • We support both ACF and Hybrid flow. However, ADRs must choose either method in their client registration, not both. • If the ADR uses Hybrid Flow, we will encrypt the id tokens in our API response. • If the ADR uses ACF, we will ignore the id token encryption fields as per the original requirement from the ACCC for FAPI phase 3. id_token_encrypted_response_alg id_token_encrypted_response_enc REQUIRED Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow. Much appreciated if we can have some urgent attention and response from your end regarding this query. Follow-up question: an you please advise if her first bullet point on supporting hybrid and code flow but not both at same time, one must be picked at registration was addressed?	This was addressed via GitHub: https://github.com/ConsumerDataStandardsAustralia/standards/issues/298#issuecomment-1543393740
1776	This question is probably one for the CX team, or perhaps the rules team if not. Happy for this one to go into the CDR Implementation Call. During the collection and use consent process, the rules currently require that the consumer be allowed to actively select the data clusters which apply to the collection consent. Is it acceptable to perform a hard validation and prevent a customer from proceeding to grant consent if they have chosen no data clusters or insufficient data clusters to enable the any requested use? For example, if the customer chose the transaction data cluster and not any other then the transaction data would be inaccessible anyway because no accountIds are available to access the transactions endpoint)	Thank you for your enquiry and apologies for our delayed response. We note that the current Rule 4.11 does not appear to require or prevent an ADR finalising a consent where a consumer has selected no data clusters or insufficient data clusters that would be required for the requested service. As such, we consider that an ADR could perform a hard validation and prevent a customer from proceeding to grant consent if insufficient data clusters have been selected.
1842	https://cdr-support.zendesk.com/hc/en-us/articles/5081838045967-Guidance-for-Profile-Scope-and-Standard-Claims - If a Data Holder receives a request from an ADR to share both the CDR Consumer's and Authenticated User’s data, e.g. common:customer:detail:read and OIDC Profile Scope, if the Data Holder determines that we must not share the CDR Consumer’s data under the rules, e.g. due to a temporary block, then must we also not share Profile Scope information for the authenticated user (Nominated Representative or a Power of Attorney), even though the temporary block does not apply to them?	Thank you for your enquiry and apologies for our delayed response. Rule 4.7 of the CDR rules provide circumstances where a data holder may refuse to disclose required consumer data in response to a valid consumer data request. These circumstances are: if the data holder considers this to be necessary to prevent physical, psychological or financial harm or abuse; or in relation to an account that is blocked or suspended; or in circumstances (if any) set out in the data standards. An account is considered blocked or suspended if it is currently not operative or usable (for example, if the account itself had been blocked or suspended due to suspected fraud). If a data holder has refused to disclose required consumer data in accordance with rule 4.7, this refusal should only apply to the relevant data as set out in rule 4.7. That is, where an account is blocked or suspended, a data holder may refuse to disclose required consumer data that is in relation to the blocked or suspended account. Required consumer data, which is not in relation to the account that is blocked and suspended should still be shared if there was a valid consumer data request. As such, a data holder may refuse to share data for a CDR consumer’s account that is temporarily blocked but can share data for an authenticated user under the same request, if the temporarily block is not relevant to their account. In relation to an account which is blocked or suspended, please note that this would not include where an account is ‘temporarily locked’ due to a number of failed login attempts or a forgotten password as the account does not fall into the meaning of a ‘blocked or suspended account’ in rule 4.7 as the account itself is still active (for example, transactions could still be made on the account). A data holder should not ignore or refuse to disclose required consumer data outside of the circumstances set out in rule 4.7.
1969	I have a question regarding nominated representatives for an energy sector data holder. CDR Rule 1.13(1)(c) states a data holder must provide each eligible CDR consumer that is not an individual with a service that can be used to nominate “one or more” nominated representatives. Nominated representatives of non-individuals and partnerships in CDR Fact Sheet (Dec 2022) confirms this. However, there is no guidance on how many “one or more” means. Is there an industry standard or expectation of how many “more” equates to? For example, if a data holder’s existing system can provide access to “two nominated persons” is that sufficient to meet the requirement of “more than one”? Or is the expectation that a system should be able to cater for an unlimited number of nominated representatives? I’ve been unable to find any guidance on this having reviewed, FAQs, CDR articles and the Explanatory Statement accompanying the Competition and Consumer (Consumer Data Right) Amendment Rules (No. 3) 2020. Any guidance would be appreciated.	The nominated representative rules are principles-based and non-prescriptive. We expect data holders to provide processes for their non-individual and partnership customers that minimise friction and can accommodate existing industry systems where possible. The CDR Rules do not provide any information or guidance on the phrase “one or more”. As such, we consider that rule 1.13(c) does not prescribe a number that this must be and there is no legal requirement that the system must be able to cater for an unlimited number of nominated representatives. It is up to the data holder to consider how they will design their systems, including the number of nominated representatives that can be appointed.
1972	Is there any obligation for Data Holder related to the changes in the Certificate Signing Request Profile table. Made following changes to Certificate Signing Request Profile table: + Included additional fields that can be provided in a CSR + Changed 'Common Name' to 'Software Product Name' only for client certificate + Changed 'Organization' to include the Brand Name only + Added column indication which fields are mandatory + Included a statement noting that if optional fields are required then they will be validated to ensure correctness	Thank you for your enquiry. The changes made to the Certificate Signing Request (CSR) Profile table in the latest Standards release have no impact on participants. These rules were already in effect and were manually being validated by the ACCC Technical Operations team. As such, the changes to the ‘Common Name’ and ‘Organisation’ fields were already implemented before amendments to the CSR Profile table were made. This is because the ACCC would liaise with participants where the ‘Common Name’ and ‘Organisation’ fields did not match the Software product name or Brand name respectively. We also note the change to the ‘Common Name’ field only affects data recipient software products and has no impact on data holder server certificates. As you have flagged, the Standards were also updated to include additional fields that could be provided in a CSR. We note that participants could always include additional fields. Hence, the CSR was updated to include guidance on how additional fields should be entered and how they would be validated. Furthermore, an additional column was included to highlight which fields were mandatory or optional. We note that previously only mandatory fields were included in the list however, it has now been expanded to cover any additional fields that could be optionally included. As a result, a statement noting the impact of optional fields was added to ensure that the field would not be ignored and participants were aware that it would be manually validated by the ACCC team to ensure correctness. Therefore, the Standards were updated to ensure alignment with the manual validation that was being performed by the ACCC team and the recent amendments to the CSR have no impact on participants.