ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 8th of September 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: [email protected]

Phones - AUDIO ONLY

Primary Australia: +61-2-9338-2221
Quick Dial: +61-2-9338-2221,,1650705270##
Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
Meeting Number/Access Code: 165 070 5270

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.18.0 Published	Link to change log here
Standards	Version 1.19.0 Staged Those interested can view the Release Branch on Standards Staging here	Target release date: late this week to early next week
Maintenance	Maintenance Iteration 12	Meeting next week on the 14th of September 2022
Maintenance	Decision Proposal 259 - Maintenance Iteration 12	Changes, meeting notes and updates for the iteration can be found here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	31st of August 2022	View in browser here
DSB Newsletter	2nd of September 2022	View in browser here
Consultation	Normative Standards Review (2021)	No Close Date Link to consultation
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Noting Paper	Noting Paper 255 - Approach to Telco Sector Standards	Link to consultation
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Consultation	Decision Proposal 263 - Telco Accounts Payloads Feedback closes: 16th of September 2022	Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language Feedback closes: 15th of September 2022	Link to consultation
Feedback	Feedback on the CDR Implementation Call Seeking informal feedback on the CDR Implementation Call. What we can improve, what you find value with and any other ideas	Link to survey
Privacy	The OAIC has commenced consultation on draft updates to the CDR Privacy Safeguard Guidelines Feedback closes: 7th of October 2022	Consultation on draft updates to the CDR Privacy Safeguard Guidelines Link to Consultation
Secondary User	Guidance article: Ceasing Secondary User Sharing	Link to the CDR Support Portal
End of year	Starting to plan out end of year shut down period.	The DSB will issue a survey in the coming weeks to get insight into when the CDR Implementation Call should pause in 2022 and recommence in 2023

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 - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Banking, Engineering & Register	Mark Verstege

Presentation

None.

Q&A

Questions will be received by the community via WebEx 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
1247	In your response you have mentioned the definition of joint account and that each “individual is acting in their own capacity”. And is eligible in relation to the data holder. I have some further questions on this: Given all joint accounts have a default setting of “pre-approved” from the rules, meaning that only 1 account holder needs to activate data sharing – does this therefore mean that the account holder is not acting in their own capacity but in the capacity of other account holders too? Our accounts are all set up with access tokens, meaning that we consider them to be eligible for online banking, they just need to register on our portal. Does that then mean they do meet the definition of being “eligible in relation to the data holder”? In relation to the link you sent in your response, the eligibility link still refers to the old (schedule 3 2.1) “set up in such a way that it can be accessed online” however the rule has changed to “the person is able to access the account online” – is someone able to please explain to the non-lawyers (i.e. me!) what the difference is please?....	In relation to your first question, rule 4A.5(1)(a) states that “the pre‑approval option, under which joint account data may be disclosed in response to a valid consumer data request on the authorisation of the requester without the approval of the relevant account holders”. This means that under this option, the account holder is making that request in their own capacity and not in the capacity of other account holders. They do not need the approval of the other account holders. In relation to your second question. Under the CDR Rules, for a CDR consumer to be eligible in the banking sector, it is not sufficient that the account could be accessed online after they register or set up the relevant credentials. The answers to questions three and four in Definition of an eligible CDR consumer guidance should assist to provide clarity. We note that the CDR Rules use both phrases ““set up in such a way that it can be accessed online” and “the person is able to access the account online”. Despite the difference in the wording in the CDR Rules, both phrases should be taken to have the same meaning.
1650	Few weeks ago during CDR implementation call, we have asked the below question. Please let us know any response. Q: Can a nominated rep authorise a single consent with both individual and business accounts (where they have the privilege to act as nominated rep) together? Q: If yes, then what data standards language do we need to display in the UI, is it for individual or business ?	In relation to your first question, the nominated representative rules are principles-based and non-prescriptive. They aim to provide flexibility for data holders dealing with a diverse range of non-individuals and partnerships. The rules are intended to accommodate existing industry processes and systems where possible, encourage innovation, and introduce an approach that can apply economy wide. Whether or not a nominated representative can authorise a single consent with both individual and business accounts together is likely to depend on what credentials the data holder will use to authenticate the nominated representative on their system - for example, whether the credentials includes the individual’s business employee/representative profile (where that exists) or their individual personal profile (as the individual may also hold personal accounts with the data holder). The data holder can decide what appropriate credentials are for the purposes of sharing a non-individual or partnership’s CDR data. Data holders have some flexibility as to how they manage nominated representatives who are linked with multiple accounts. The ACCC has developed guidance on nominated representatives which can be found at Nominated representatives, non-individuals and partnerships in the CDR. The guidance in relation to the What happens after a nominated rep is authenticated? question outlines a (non-mandatory) profile selection step which could be implemented where a nominated representative is linked to multiple accounts and this step reflects the existing customer experience. In relation to your second question, if a scenario allows the sharing of individual and business accounts in a single consent, the data language standards would only differ for the customer language (i.e. common:customer.basic:read or common:customer.detail:read). The language standards for all other data clusters are agnostic. Importantly, the person authorising the sharing of data is not equivalent to the CDR customer for the purposes of the customer data cluster. As the response to Q1 suggests, the expectation is that data holders will request that the person who is able to be an individual or a nominated representative specify the context in which they are sharing. The consent will then be established in that context, which will also determine if the DH is to use individual or business customer language.
1692	Is it correct to assume that the below accounts are not eligible for sharing even after 1 November 2022 as the Rules don't have any provisions for them. - Accounts held jointly by an individual and a business - Accounts held jointly by 2 or more businesses Joint accounts are clearly only covered by the Rules when all account holders are individuals. So the joint accounts provisions do not apply. But it does not sound right to share data from these accounts without informing the other party, an apart from the joint accounts there is no other provision in the Rules that states that a customer can see another customer's consents.	You are correct that the accounts held jointly by an individual and a business or held by 2 or more businesses are not eligible for sharing after 1 November 2022. This is because these types of joint accounts are not eligible under the joint account provisions and there are no other provisions in the CDR Rules that would currently allow disclosure for these types of joint accounts.
1693	The original question was about the definition of a customer across different business units/channels, where they may be an eligible customer of the 'data holder' but do not have access to the same servicing channel. I don't think the article provided as an answer covers joint accounts or this type of scenario, it seems to focus on the distinction between individual and non-individual customers. Are you able to provide any further insight about joint accounts where a party does not have online access to the same channel as the other party? Could they just be considered ineligible?	As stated in this knowledge article, “If the CDR consumer is eligible for at least one account, then all other accounts they hold with the data holder - whether or not those other accounts are located on a different digital channel - must also be available for CDR data sharing.” This is because eligibility for the CDR in banking is determined by whether a consumer has any account open with the data holder that is set up in such a way that it can be accessed online (see rule 1.10B and sch 3, cl 2.1 of the CDR Rules). If the consumer has one such eligible account, regardless of whether their other accounts are on a different servicing channel, all other accounts that consumer has with that data holder must be available for data sharing, including joint accounts. Therefore, the type of account does not affect our guidance in the linked knowledge article.
1642	I am referring to the laggards (the DH's who haven't really built the support for PKCE) after the 16th of September, The ADRs will send the PKCE requests and if the DH continues to ignore the PKCE claims then no harm is done in the sense, the consent flow would proceed however the intent of the FDO is not met. How is this scenario captured/monitored by the DSB/ACCC? Agree with your comment that if an ADR does not support PKCE and a DH mandates this from the 16th of September, all consent/authorization requests will be rejected. Are all ADRs currently supporting PKCE and ready for the 16th Sept?	The DSB cannot comment on how the ACCC will monitor this. If you have any queries around compliance and enforcement it would be best to contact CDR Technical Operations mailbox [email protected]. Regarding ADR compliance, again, this is a matter for the ADRs to ensure they are compliant with their data standards requirements.
1696	We noticed PAR examples provided by RFC9126 and CDS are quite different. The example from RFC9126 is inline with OIDC however the CDS example is not. The example from section 2.1 of https://www.rfc-editor.org/rfc/rfc9126 is as follows : POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded The example from CDS https://consumerdatastandardsaustralia.github.io/standards/#security-endpoints under the section named "Pushed Authorisation End point" has the following example : POST /par HTTP/1.1 Host: data.holder.com.au Content-Type: application/x-www-form-urlencoded request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey... My question is, which example should we follow ?	Please follow section 3 of PAR RFC9126. The data standards follow FAPI and require the use of the signed request object for submission of authorisation parameters.
1701	How is an ADR expected to handle URL encodable ASCII characters which are included in ID permanence fields such "/" or "%". Noting the standards advise that the IDs being returned can contain any valid ASCII character. Example : If a DH returns the account ID as "AHSUgD1234/ahad^&%" , should the subsequent transactions invocation be a. GET /banking/accounts/AHSUgD1234/ahad^&%/transactions , or b. GET /banking/accounts/AHSUgD1234%2Fahad%5E%26%25/transactions It might be helpful to participants if guidance about this is added to the CDS at https://consumerdatastandardsaustralia.github.io/standards/#id-permanence	Resource API calls need to be url encoded.
1702	Part 1: Option 1 in Issue 533 indicates that Data Holders cannot cutover to FAPI 1.0 Advanced + PAR + PKCE prior to September 16th 2020. However, CDS Specs mention that DH "may" support FAPI 1.0 Advanced Profile from 4th July 2022. Link to 533: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/533 Link to CDS Spec: https://consumerdatastandardsaustralia.github.io/standards/#authentication-flows Part 2: Also on Issue 533, (options 2 and 3) our interpretation is that FAPI 1 Advanced specification REQUIRES use of PKCE on PAR endpoint and therefore we cannot relax that part of the specification in our implementation. Is our interpretation correct? Section 5.2.2 (FAPI Spec) In addition, the Authorization Server 18. shall require PAR requests, if supported, to use PKCE (RFC7636) with S256 as the code challenge method.	That is correct - this is why the change request was raised. If no further feedback is received, Option 1 is the default position.