ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 20th of April 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.23.0 published 14th of April 2023	Version 1.23.0 Change Log
Standards	Proposed next version(s) of the Consumer Data Standards: 1.24.0	Version 1.24.0 is planned to contain changes from Maintenance Iteration 14
Maintenance	Iteration 14 is complete!	All the Meetings notes
Maintenance	Iteration 15 is planned to commence on the 3rd of May 2023 Invitations and details to be sent	Intent is release Versions 1.23.0 and 1.24.0 of the Consumer Data Standards prior to the commencement of MI15
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	21st of March 2023	View in browser here
DSB Newsletter	14th of April 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	Noting Paper 296 - Offline Customer Authentication	Feedback 21st of April 2023 Link to consultation Video 55 of NP296
Consultation	Noting Paper 289 - Register Standards Revision	Feedback 28th of April 2023 Link to consultation Video 56 of NP289
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	CDR Register	Eva
ACCC	CTS	Andrea
DSB	CX Standards	Amy
DSB	Technical Standards - Banking & Information Security	Mark
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Telecommunications	Brian
DSB	Technical Standards - Register	James

Presentation

None 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
1259	Hoping to clarify the below questions around notifications around consent revocation/cancellation at data holder’s end (non customer driven) – Would like to understand Data Holder obligations around sending notifications to ADR in the event of revocation/expiry of consent by data holder (non customer driven) as a result of a customer becoming an ineligible CDR consumer (business scenarios identified are outlined below) Would also like to understand what end points are to be called at the ADR end and whether they will trigger any notifications to the customer (from the ADR). – The reason for this question is to do with one of the scenarios identified (outlined below) around the customer being deceased, as we would not want any communication to go out to the customer in this sensitive case (from DH directly OR from the ADR) unless mandated for a reason Would also like to understand Data Holder obligations around sending notifications to customer directly in the event of revocation/expiry of consent by data holder (non customer driven) as a result of a customer becoming an ineligible CDR consumer (scenarios identified are below) – Is there any obligation other than updating the customer’s dashboard as soon as the customer’s consent changes. (Also, noting that the customer would not have access to their primary digital channel to access their dashboard). Business scenarios outlined below for context - In a post consent (i.e. active consent arrangement in place) context, below are some few business exception scenarios identified where we (as a Data holder) think that consents will need to be revoked/cancelled (non customer driven) - 1) Customer has become CDR ineligible (Rule 4.26(1)(c)) due to the fact that they have closed ALL accounts with DH 2) Customer deceased (zendesk article) and therefore become CDR ineligible 3) Internet Banking (IB)/Customer ID is compromised and customer’s primary digital channel access is cancelled, therefore becoming CDR ineligible (Rule 4.26(1)(c) and Schedule 3 (2.1)(2)(b)(ii)) 4) Edge case scenario - Customer is confirmed as a fraudulent customer and their primary digital channel access is cancelled permanently (after entering in an active consent arrangement), therefore becoming CDR ineligible (Rule 4.26(1)(c) and Schedule 3 (2.1)(2)(b)(ii))	Thank you for your query and apologies for the delay in our response. In relation to questions 1 and 3, we note that the CDR Rules do not require a data holder to notify the accredited person or CDR consumer where the authorisation has expired due to the CDR consumer no longer being eligible under rule 4.26(1)(c) of the CDR Rules. The obligation to provide a dashboard under rule 1.15(1) would also cease to apply where a CDR consumer is no longer eligible (see rule 1.10B, clause 2.1 and clause 2.3 of Schedule 3 to the CDR Rules). Note however that if a CDR consumer’s online account is only temporarily blocked or suspended, our view is this would not cause a CDR consumer to be ineligible in relation to the data holder. Please see here for further information. In relation to question 2, the DSB has advised that the CDR Arrangement Revocation endpoint hosted by the ADR is called when consents are withdrawn by the Data Holder. This will trigger ADR notifications to the consumer. There is no way to inform an ADR not to send out notifications. The only solution in this scenario is for the DH to not withdraw the consent but block all data sharing requests and access under that ineligible consent.
1772	Is it mandatory, to show both states on a dashboard? If yes, are we allowed to decide the state name for each of the states?	Updated: CDR Support Portal: Consumer Dashboard - revoked and expired consents
1916	I have a question regarding Get Telco Invoices API. As our current plans have unlimited national calls and data, and we do not currently provide the duration / data usage to the customer in the invoice, my question is what is the expected value we should provide as Data Holder in above APIs? I am using the following schema as an example. Do we not track the duration and the number of national voice calls to customer. What is the valid response in the above circumstances??	Under the “draft” telco rules, its implied usage data is required. I understand in some instances this may not be available. With regards to ‘balances’ we provide a “planType”: - METERED: A plan is charged by usage for the feature - UNMETERED: A plan with no limits for a feature - LIMITED: Where plan limit inclusions apply - UNSUPPORTED: Feature is not supported However, we do not apply this to ‘usage’. We can look to add this, so usage would be conditional. i.e usage is required unless planType is UNMETERED or UNSUPPORTED which is what is done for Balances. This would be a change to the Telco Standards. It will require some consultation with other agencies and the community. I also note “accountUsage” on TelcoInvoice is marked as optional. It should be Mandatory or if we make the change above it would be Conditional. So the options we can consider here are: - Leave it as is (optional), No change - Make it conditional (if the data is available), Description change non breaking. - Make it conditional bases on planType (as above with balances). Breaking change. I would ask that you add this feedback and suggestion to the Holistic feedback thread for Telecommunications Standards: Decision Proposal 302: https://github.com/ConsumerDataStandardsAustralia/standards/issues/302 This is the best way to add feedback with the community.
1933	would you confirm that a sponsored third party sponsored by an unrestricted data recipient may be able to rely on the self assessment questionnaire in lieu of a soc 2	Thank you for your enquiry. By a sponsored third party sponsored by an unrestricted ADR, we are assuming you mean an accredited person with sponsored accreditation, not another type of third party. Sponsored accreditation applicants are not required to provide an independent third-party assurance report (such as SOC 2) to demonstrate that they satisfy the information security obligation. Instead, where an applicant has, or will have, an arrangement with an unrestricted accredited person (their sponsor), the applicant may apply for accreditation at the sponsored level and should use the self-assessment and attestation form to show that they satisfy the information security obligation. The template for the self-assessment and attestation form can be found on the Forms and templates page of the CDR website.
1935	Obligations on ADR when transitioning from Hybrid Code flow to Auth Code flow Reference: (Applicable Date: April 14th 2023) FAPI 1.0 adoption is introduced across four phases. Phase 3: Support Authorization Code Flow and Hybrid Flow includes, amongst other changes: Data Holders MUST support Authorization Code Flow Data Holders MUST support Hybrid Flow The Hybrid flow requires the ADR to have a registration with the DH ( response_type of code id_token) The Auth Code flow requires the response_type of code. So are the ADRs expected to hit the DH /register (Update Data Recipient Registration) with changes to the response_type values before they make any auth code flows? if this is the plan, then are all the ADRs aware that they would fail if they don't make this call before making the auth code flow to DH. New ADRs starting with auth code flow will not have an issue. The query is about ADRs who have already registered with the DHs and making the switch (from hybrid to auth code flow)	Yes, ADRs will need to go through a DCR update for any existing client registrations before they begin to use the Authorization Code Flow. This is standard OIDC base standard behaviour. An authorisation server will expect a client to act according to its registration regardless of how that registration was created. It is helpful to understand that this is not generally known among the ADR community. We will make an effort to communicate this necessity.
1939	Standards 1.23.0 removed a requirement prohibiting ID token encryption when using code flow, and in doing so seems to have an implication that any identity provider which still supports hybrid flow will also support id_token encryption for code flow (due to the discovery document stating that encryption is supported, which doesn’t distinguish between flow types). We believe this implication is not intended, and that it is still acceptable for a solution to explicitly not support id_token encryption with code flow even if the discovery document states that id_token encryption is supported. Please confirm?	The change in 1.23.0 facilitates data holders that cannot differentiate between Authorization Code Flow and Hybrid Flow during transition. Until such time that the Data Holder drops Hybrid Flow and the ADR updates their client an ADR may have their oAuth client registered for both ACF and Hybrid flow. A Data Holder must support ID token encryption for Hybrid Flow because this is a FAPI 1.0 requirement to protect the ID token sent in the front channel. It is at the discretion of the data holder if they perform ID token encryption for ACF. Some Data Holders indicated they cannot conditionally differentiate ID token encryption for ACF and Hybrid flow. Hence the change in 1.23.0 to support them. Any holder that can conditionally deal with this scenario can do so and the ADR should be expected to check the JOSE header of the nested JWT to determine the encryption used. If none is present they can then proceed to checking the JWT signature. We are actively encouraging ADRs to test their solution for ACF during the transition window and update their client registration to only use ACF before the July 10th obligation date that permits holders to retire Hybrid Flow. The transition window provides a safer path for ADRs to update their client software in a rolling fashion across all data holders whilst ensuring they have a fallback mechanism if any given data holder has not correctly implemented ACF.