ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (11th of March 2021)

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (11th of March 2021)

When: Weekly every Thursday at 3pm-4.30pm AEDT
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:

Desktop or Mobile Devices https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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: 785383900@csiro.webex.com

Phones - AUDIO ONLY

• Primary Australia: +61 2 6246 4433
• Quick Dial: +61262464433,785383900%23%23
• Other Global Numbers: https://conferencing.csiro.au/Call-in.php
• Meeting Number/Access Code: 785 383 900

---

Agenda

1. Introductions
2. Actions
3. CDR Stream updates
4. Presentation
5. Q&A
6. Any other business

Introductions

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

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 contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.

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.

Updates

Type	Topic	Update
Standards	Version 1.7.0 Published	Link to change log here
Maintenance	6th Maintenance Iteration underway for 2021	Read about the Maintenance Iteration - If you would like to join these please reach out to contact@consumerdatastandards.gov.au
Maintenance	Decision Proposal 161 - Banking Maintenance Iteration 6	Link to consultation
DSB Newsletter	To subscribe to DSB Newsletter	Link here
ACCC Newsletter	To subscribe to ACCC Newsletter	Link here
ACCC Newsletter	3rd of March 2021 Edition	View in browser here
DSB Newsletter	5th of March 2021 Edition	View in browser here
Consultations	Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users	Link to consultation
Consultation	Decision Proposal 162 - CX Standards, Joint Accounts, Authorisation Flow	Link to consultation
Consultation	Decision Proposal 164 - Endpoint Metrics	Link to consultation
Consultation	Decision Proposal 165 - Brand aware metrics	Link to consultation
Consultation	Decision Proposal 166 - CX metrics for Data Holders	Link to consultation
Consultation	Decision Proposal 167 - Direct to consumer	Link to consultation
Consultation	Decision Proposal 168 - Separate Consents, Authorisation Withdrawal	Link to consultation
Consultation	Noting Paper - White Label Conventions	Link to consultation
CDR Support Portal	Article Updated on Sample List of CTS Test Scenarios	CDR Support Portal Article

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation	Stream	Member
ACCC	Rules team	Paul Franklin
ACCC	CDR Register (Technical)	Ivan Hosgood
ACCC	Onboarding	Jorina van Malsen
DSB	CX Standards	Michael Palmyre
DSB	Technical Standards - Banking	Mark Verstege
DSB	Technical Standards - Energy & Engineering	James Bligh

Presentation

No presentation this week.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

Current received pre-submitted questions:

Answer provided

Ticket #	Question	Answer
531	Please refer to the attached document (not included here on Github) for more details, but in summary we would like to know if we can replace the certificate thumbprint with certificate serial number (and/or issuer) during HoK token confirmation.	The upstream standards (OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens: https://tools.ietf.org/html/rfc8705) states the following: When access tokens are represented as JSON Web Tokens (JWT)[RFC7519], the certificate hash information SHOULD be represented using the x5t#S256 confirmation method member defined herein. There has been no rationale to deviate from this and it is expected data holders will use this method.
560	Can you please advise if the CTS tool is expected to be connected to an organisation’s production or non-production environment to run the tests? I understand the documentation states that the solution needs to be production ready, however wanted to get confirmation on the expectation when running these tests.	Participants can connect any environment to the CTS for the purpose of testing, production or any lower environment. CDR Support Portal Article
600	Does that mean "infosecBaseUri" will serve base-path for both public (TLS) and private (mTLS) URLs ? Public (TLS) URLs: - OpenID Provider Configuration End Point - Authorisation End Point - etc., Private (mTLS) URLs: - Token End Point - UserInfo End Point	that would be the common expectation however InfoSecBaseURI is used primarily to allow ADRs to locate the OpenID Connect Metadata endpoint. The metadata response from this endpoint contains the URLs of each of the various info sec endpoints so the URL for each of these is at the discretion of the DH CDR Support Portal Article
608	Can the Simulated Test Register and Simulated Data Holder be common and shared between 2 ADR's (Principal and Provider in a collection arrangement) ? Is there any ownership defined here?	I interpret your question to mean, during execution of the Conformance Testing Suite (CTS), will the Principal and Provider both be involved in the process? If this is a correct interpretation, the answer is yes. The collection arrangement concept allows the Principal and Provider to act as a single entity when engaging with the Data Holder. Going through the CTS process, the collection arrangement participants will provide their software product and platform together. The Principal owns their entry's in the CDR Register but can work with the Provider to ensure that that the Provider's services are appropriately configured in the Register. I hope this is clear. As I don't know the arrangement you have between Provider and Principal, I am unable to provide specific examples. If you require further details, please outline which party is providing which services. The collection arrangement article outlines various service categories which the Provider may offer to the Principal. CDR Support Portal Article
613	In the ACCC Newsletter today, there was a section on Version 2 of the CTS as below. It states that additional scenarios have been included in the CTS. The link that is included takes you to the same list of CTS scenarios where the document is at V1.0. This was something that we had previously downloaded. Is there expected to be a revision of this document to include these additional scenarios mentioned? Appreciate if the team could clarify. Thanks. Version 2 of the Conformance Test Suite (CTS) was released on 18 February 2021, and is now available for new data holders and accredited data recipients to on-board to the Consumer Data Right. Additional test scenarios to support information security and consent have been included to increase the robustness of testing via the CTS.	Updated CDR Support Portal Article
619	The new optional "legal_entity_id" and "legal_entity_name" fields are listed as not updatable in the SSA definition in the Dynamic Client Registration section of the new v1.3.0 standard. In particular the current specification implies that those two claims are optional during client creation, but once the client is created, they cannot be updated to add them. We would appreciate it if the ACCC could confirm that this was intended or advise if it was not intended and amend the documentation.	The behaviour you have described is correct and I will elaborate here: 1. Data holders introducing support for "legal_entity_id" and "legal_entity_name" would result in empty fields being made available in their identity stack 2. The data recipient isn't aware of data holder support for these new fields and will only know if supported after the registration has been updated and appropriate values returned 3. If the data holder does not support these new fields, it should ignore these fields rather than return an error 4. Once included, these values are immutable. We currently flag the field as "optional" and once we are confident that support is ubiquitous, the documentation will then be updated to flag this as mandatory. This is by design as the future obligation dates are We are working through SSA Change Management as part of Design iteration #1 so there is an opportunity for feedback once we have published our current process. CDR Support Portal Article
622	are there any dependencies in regards to Authorisation Scope and Consents? For example on one account could a customer Authorised bank:accounts.basic:read and Collection Consent and on another account the same customer Authorise bank:payees:read and Use Consent? And technically, but not practical, could a customer Authorise just bank:accounts.detail:read and Use Consent? (note, no Authorisation of bank:accounts.basic:read and no Collection Consent) Attached is a matrix of the options, can the cells in yellow (C3 to G10) be accepted independent of any other Authorisation and Consent combination?	We're not entirely sure we understand your spreadsheet so we won't comment on that specifically. That said, a single consent has a set of scopes and a set of attached accounts. Data sharing for all attached accounts is according to the authorised scopes. There is no situation where account specific scopes are created in the CDR. That said, it is entirely possible for a consumer, with the same ADR, to create many different consents each with different sets of scopes and different sets of attached accounts if they wish and if the ADR supports this scenario. CDR Support Portal Article
625	Is a regular payment where the payment has been initiated by bank on customer's behalf considered as a schedule payment? Use case example: 1. Regular payment setup to pay the loan amount on the repayment due date considered as scheduled payment? 2. Regular payment setup to pay the credit card balance on scheduled date considered as a scheduled payment?	These could be considered scheduled payments. It is, at the discretion of the Bank how they represent these items to align with how they would represent these types of payments in other channels. We have a convention that covers this topic, which might help you: CDR Support Portal Article
627	In circumstances where a DH offers payments utilising internal systems, i.e. leveraging internal routing as opposed to BIC codes (or similar), would payee information for these transactions need to be shared given there is no conventional routing included in the data? It is anticipated that where sending funds to this payee outside of the DH's ecosystem could result in negative customer experience as shared payee data would be incomplete.	This scenario has never been raised before but, having reivewed the standards, the only mandatory fields for an international payee are the name, country and address of the bank which, for an internal customer, should be known by definition. Presumably the routing codes for your own institutions would also be known? CDR Support Portal Article
628	Have few questions on the arrangements revocation end point that is to be hosted by the data recipient. 1.Does it have to be /arrangements/revoke? can DR specify any other sub-path instead of /arrangements/revoke? 2. Was looking for example of DH calling DR for revoke. Example "Non-Normative Example - Data Holder calls the Data Recipient's revocation end point" shows a Bearer token in header, would be this in addition to client_assertion JWT? 3. When DH calls DR /arrangements/revoke end point, in case input cdr_arrangement_id is valid but DR fails to process it, any guidelines on how this situation needs to be handled? 4. Upon receiving a revoke request, can DR do that actual data deletion as an offline process? As in can DR just acknowledge the request and send 204 response, but do the actual data deletion process at a later point?	Q: Does it have to be /arrangements/revoke? can DR specify any other sub-path instead of /arrangements/revoke? A: Yes, it has to be /arrangements/revoke as defined explicitly in the standards. Otherwise data holders will have no idea how to call it. Q: Was looking for example of DH calling DR for revoke. Example "Non-Normative Example - Data Holder calls the Data Recipient's revocation end point" shows a Bearer token in header, would be this in addition to client_assertion JWT? A: No. As per the Data Holders calling Data Recipients sub-section of the standards in the Client Authentication section an ADR will authenticate a call from a data holder using a JWT as a bearer token. This is to avoid the ADR having to implement a full authorisation server for one end point. **Q:**When DH calls DR /arrangements/revoke end point, in case input cdr_arrangement_id is valid but DR fails to process it, any guidelines on how this situation needs to be handled? A: Presumably this shouldn't happen? If it does, it would imply a server error of some sort so a 500 should be returned with the appropriate CDR compliant error payload. Q: Upon receiving a revoke request, can DR do that actual data deletion as an offline process? As in can DR just acknowledge the request and send 204 response, but do the actual data deletion process at a later point? A: The standards do not specify any requirements in this scenario so the behaviour is entirely governed by the CDR rules. Refer to the CDR data deletion process and clauses related to Withdrawal Of Consent in the rules for more information. It is the understanding of the DSB that the rules explicitly and clearly state the requirements for ADRs in this regard. It is the obligation of CDR participants to read and reasonably comply with the rules as written. CDR Support Portal Article and CDR Support Portal Article
636	This is a follow-up to your previous request #377 "Sample values for Software ID used in the SSA" Few follow up questions? (1) what are the URL equivalents in the cdr-register for the data holders? You had mentioned this URL ->https://api.cdr.gov.au/cdr-register/v1/banking/data-recipients which lists all the recipients? (2) The Data recipients URL will provide only the recipients that have been active at some point (in their lifetime? There are others such as CBA who are accredited however they are not in an active state and they are not visible in that URL.	The Register APIs section of the CDR Register Design outlines which APIs are exposed and who is expected to call them 2. The APIs only expose entities which have been activated. There is work in flight to determine at what stage a deactivated entity will no longer be returned from the APIs. This work is being tracked under: https://github.com/cdr-register/register/issues/164

Response pending

Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.

To our valued CDR participants, In light of the movement of the Rules function to the Treasury, we are assessing the current support structure and requests open on the CDR Support Portal. We kindly ask for your patience as we work our way through the tickets and support model; we will endeavour to get back to you as soon as possible. Thank you for your support.

Useful Links

A work in progress - open for feedback from the community on what you would like to see.

Organisation	Description	Link
OAIC	Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right	Link
DSB	CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance.	Link
DSB	Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events	Link
DSB	The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right	Link
DSB	The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right	Link
DSB	GitHub Consultations - all public consultations from the Data Standards Body	Link
DSB	Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients	Link
ACCC & DSB	The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions	Link
ACCC	ACCC Main focus area/ landing page for the Consumer Data Right	Link
ACCC	GitHub Consultations - all public consultations from the ACCC Register Team	Link
ACCC	CDR Register Design Reference	Link
ACCC	Public page for the Consumer Data Right	Link
ACCC	Participant Portal page including sign-up and log-in	Link
TSY	Consumer Data Right background and historic records from the Treasury	Link