Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (15th of April 2021)

CDR API Stream edited this page Apr 15, 2021 · 9 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (15th of April 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: [email protected]

Phones - AUDIO ONLY


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 [email protected] 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
Standards Version 1.8.0 Drafted Link to Version Project Board here
Maintenance 6th Maintenance Iteration wrapping up for 2021 Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected]
Maintenance This week is the final call of the 6th maintenance iteration. The purpose of the meeting is to review the final change candidates and future dated obligations.
Further to this, the meeting will discuss the changes to be made for the Enhanced Error Handling decision proposals.
Agenda for today's Maintenance Iteration call.
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 26th of March 2021 Edition View in browser here
DSB Newsletter 9th of April 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 173 - Energy Draft Feedback Cycle 2 Link to consultation
Workshop OIDF & DSB - Introduction Workshop & the Consumer Data Standards Register here
Workshop OIDF & DSB - Technical Workshop & the Consumer Data Standards Register here
Workshop Update on White Label Workshop: No workshop is planned.
Based on feedback no changes to the Consumer Data Standards have been identified to accommodate the scenarios presented. Further, the DSB received no feedback on alternative white labelling models that were not satisfied by the scenarios presented.
This consultation will now be closed and marked as No Decision Taken to reflect that no changes to the standards will be recommended to the Data Standards Chair.
See Noting Paper for feedback on commentary provided.
Action * If CTS does not support Client Authentication improvement, will a Holder be able to pass early?
* CDR Register introduced new fields in the SSA which are effective "from July 2021". Is a holder expected to support this during onboarding? Does CTS test?
* Does the CTS support ES256 signatures and tokens?
* CTS Delivery Schedule
Ivan to update the Community

CDR Stream Updates

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

Organisation Stream Member
ACCC CDR Register (Technical) Ivan Hosgood
ACCC Onboarding Chantelle Demian
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.

New Experiment for Q&A

We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #11096

Answer provided

Ticket # Question Answer
389 Part 2 Part 1 Thanks for the response it clarifies. Have a follow-up question on the certificates which will be hosted via JWKS by the Provider in this case when it is serving multiple Principals.
1. Same JWKS can be used by the Provider for multiple Principals. Is this correct?
2. What type of keys need to be hosted in JWKS? We know that there needs to be public key which will be used by CDR/DH to verify the JWT that are issued by Provider. Should it also include public key which is to be used for id_token encryption by DH?
3. As Provider is serving multiple Principals, what would be expectations around keys hosted in JWKS? Specifically anything around key rotation and any other non-functional requirements? Couldn't find this information in certificate usage policy.
1. JWKs should be treated the same way as CA issued certificates. The CDR Register provides the functionality to have a dedicated JWKS endpoint per software product.
If JWKS endpoints are to be shared (which they can be by duplicating the jwks_uri for each software product) dedicated keys should be issued per software product.
2.ID token signing and encryption public keys should be published on the corresponding JWKS endpoints.
3. We don't specify key rotation requirements. Organisations are responsible for their own certificate and key rotation policies. However we do provide recommendation on cache age for clients retrieving JWKS. Clients are recommended to have a maximum cache age of 15 mins.
Please consult your security team to determine how your organisation manages these keys and their rotations. The CDR Register provides for many different configurations and it is up to each organisation to ensure best practices are followed.
Please let me know if you have any further questions.
603 Q1. In terms of exposing Data Recipient information to consumers, are there any CDR directives on exactly which data properties are required to be exposed as a minimum on the Data Holder Dashboard when displaying the list of active or archived consent agreement and/or the details of a consent agreement for the consumer? The get data recipients endpoint response appears to have 3 levels of this information to choose from (https://cdr-register.github.io/register/#getdatarecipients) as follows:
1. Legal Entity - legalEntityName, accreditationNumber, logoUri, status
2. brandName - brandName, logoURI, status
3. softwareProductName - softwareProductName, softwareProductDescription, logoUri, status
Q2. Would there be scenarios (excluding technical) where required data properties would be empty or incorrect? Eg. missing or incomplete product data or a broken logoURI? If so is the data holder required to account for missing and/or incorrect data within the CX?
Q3. Is or will there be a need to supply or expose DRSP numbers for a software product to consumers?
Q1: Are there any CDR directives on exactly which data properties are required to be exposed as a minimum on the Data Holder Dashboard when displaying the list of active or archived consent agreement and/or the details of a consent agreement for the consumer?
CX Response: The DSB will soon consult on fields to present during the authorisation flow and on DH dashboards. We anticipate a proposal for DH Dashboards to display an ADR's brand name, software product name, and legal entity. We will also recommend an ADR's accreditation number be surfaced on DH Dashboards. The level of obligation and compliance date(s) will also be subject to consultation.
We will need to take Q2 and Q3 on notice as they relate to the Register.

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, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance

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
Clone this wiki locally