-
Notifications
You must be signed in to change notification settings - Fork 56
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
- 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
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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.
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.
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 |
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 |
No presentation this week.
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.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #11096
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. |
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
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 |