ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (29th of April 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (29th 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
Agenda
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- 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.8.0 Published | Link to change log here |
| Standards | Version 1.9.0 Drafted | Link to Version Project Board here |
| Standards | Version 1.10.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 | 7th Maintenance Iteration has commenced | Agenda of the backlog session |
| Maintenance | Decision Proposal 161 - Banking Maintenance Iteration 6 | Link to consultation |
| Maintenance | Decision Proposal 178 - 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 | 22nd of April 2021 Edition | View in browser here |
| DSB Newsletter | 23rd 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 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 |
| Workshop | OIDF & DSB - Technical Workshop & the Consumer Data Standards | Register here |
| Action | Question: For the bi-annual report period ending 30 June 2021, do non-major ADIs have to include data relating to consumer data disclosures in the report? | Answer: Non-major ADIs are not required to include data relating to consumer data sharing for their rule 9.4 report for the 1 January-30 June 2021 reporting period unless they elect to share CDR consumer data before the compliance date. We do not expect test data to be included in these reports. CDR Support Portal Knowledge Article |
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 | Eunice Ching |
| 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.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517
Answer provided
| Ticket # | Question | Answer |
|---|---|---|
| 384 | Although I am still unclear about what you stated in your response: "The collection arrangement is not executed by the Provider having their own software product. As described above, the Provider is managing the software product on behalf of the Principal. Any software products that the Provider has in the ecosystem are not utilised as part of the collection arrangement. V1.3.0 of the CDR Register design adds functionality which allows the retrieval of an SSA from the CDR Register, using authentication at the software product level as well as the data recipient brand level. This is key as it allows us to define the access control of which software products the Principal can allocate to the Provider. This increases the types of models supported in the ecosystem. To repeat comments above, this new functionality does not impact the Dynamic Client Registration process." My understanding currently is that Software Product(s) of the Accredited Data Recipeints are tested via the Conformance Test Suite as part of the onboarding process. So what about in the instance where we as a Provider expect that there will be more than one ADR (acting as Principal) to be consuming through the same Software Product in question? How does this affect CTS enrolment (i.e. will the same CTS enrolment process apply to every ADR brand that is looking to consume via the same Software Product) as well as subsequent SSA retrievals (the only difference being the ADR brand IDs provided will be different but Software Product ID will be the same)? And to frame this question in another way: in the instance of a Principal (ADR) which has already been registered with its own Software Product ID - is consuming the services through a Provider (which itself already maintains its own Software Product for another Principal), should the Provider's Software use the Software Product ID of the Principal when doing Dynamic Client Registration? Or can the Principal utilize the Software Product ID of the Provider already has with the other Principal to perform the Dynamic Client Registration? | The Provider is required to use the software_product_id of the Principal's software product when performing Dynamic Client Registration. Sharing of registrations between different software products is not permitted. The Provider is effectively impersonating the principal, managing the registration, certificates and JWKS on-behalf of the Principal. Completion of CTS testing is required for each software product in the ecosystem prior to activation, regardless of whether it is part of a collection arrangement. |
| 587 | When data is first disclosed from a joint account at a later date to AH-A’s individual account(s), does AH-B see a different ‘first disclosure date’ to AH-A? | The DH needs to indicate 'when the CDR data was disclosed' in relation to the data cluster, irrespective of which account the data was disclosed from. This would differ slightly for multi-party accounts like joint accounts, where the other account holder (AH-B) would have a dashboard that shows the authorisation details where it relates to requests for CDR data in relation to their joint account(s) (see clause 4.14, Sch 3 to the CDR Rules for the full set of requirements for a joint account holder’s dashboard). The CX Guideline (p.110 of v1.4.0) provides an example of how to comply with rule 7.9 and privacy safeguard 10, and, in the above scenario, would need to be adjusted slightly for AH-B. This would require AH-B's dashboard to note when the CDR data was disclosed for the specific joint account(s) associated with AH-B that relate to the request. It would not reflect the first disclosure date of data associated with AH-A’s individual accounts. For further information on a DH’s obligation to notify of disclosure, see Chapter 10 of the OAIC’s CDR Privacy Safeguard Guidelines. |
| 643 | Using different domains for public and authenticated resource was evident. However it was not explicit for the public and authenticated infosec end points. I was seeking clarification on the latter - Infosec public vs authenticated. Does it make sense to have a separate baseURI - https://cdr-register.github.io/register/#participant-endpoints (similar to the other three) In other words, we currently have three baseURIs clearly articulating their purpose (PublicBaseUri, ResourceBaseUri and InfoSecBaseUri). Does it make sense to add the 4th one representing the authenticated InfosecBase URI? This way it is explicit and clear to everyone (and consistent with the resources - Public & Authenticated) | We appreciate the challenges in differentiating between endpoint requirements. We are planning to publish a knowledge article on the topic. The InfosecBaseUri points to the OIDC Provider Configuration Document. From here, reference to the assorted infosec endpoints such as token, authorize etc can be derived. How these endpoints are split between domains is an implementation issue for data holders to determine and they can request ACCC CA issued certificates as required. Adding these references to the CDR Register would be redundant and risk synchronisation issues as there would then be two discovery points. |
| 645 | In case if at least one account holder of the joint account has set the sharing preference as "Don't Share" in Joint Account Management Service (JAMS), can that account be catogarized as an 'unavailable' account in the consent authorization flow. | The rules are ultimately silent on this scenario, leaving it to DHs to determine. The original v1 rules JA guidance encouraged DHs to clarify why a JA couldn't be shared on their DH dashboard. Providing similar information in the authorisation flow is a logical extension of this guidance. Given the above, we recommend listing a JA with a do not share preference as an un-selectable and unavailable account in the authorisation flow. This is consistent with the CX standards on unavailable accounts. |
| 661 Part 2 | Find Part 1 here So this means that effectively the Provider's product manages everything on the backend (i.e. registration with CDR, managing consent arrangements, data collection, etc) but it can expose API endpoints (i.e. details on the consent arrangment to be provided) to the Principal such as they can then build their own customer facing front-end on top of this? | The CDR Rules don't dictate what services a Provider may offer the Principal. The article on collection arrangements takes a technical lens to the rules and articulates what services may be offered. It seems logical though that the Provider will offer all services required for data collection, leaving the Principal confident that all the security artefacts and collection logic are handled by an expert and they can focus on their own customer value propositions. The Provider can then provide an integration layer to allow Principals to build there apps on top of this, in what-ever form is appropriate to their use-case. |
| 693 | As per CDR specification on client authentication during Data Holder calling ADR (during CDR Arrangement revocation endpoint), JWT with specific claims is required. Can you please let me know who will create this jwt? Is it Data Holder? If Data Holder is creating the JWT then what would be the signing certificate and how Data Recipient will validate it. | The latest update V1.4.0 of the CDR Register Design has improved the sequence diagram which outlines this process. Please see the sequence diagram Request for Consent Withdrawal: Checking Validity of Accredited Data Recipient and associated Software Product The data holder is responsible for creating this JWT which the data recipient then validates the signature. Data recipients authenticate data holders using JWKS specified in data holder brands discovery APIs. |
| 715 | The "page" and "page-size" request query parameters are not a mandatory field in the GetDataHolderBrands API. 1. Are we supposed to pass a value in these fields when making the GET call? 2. Any default values for these fields? 3. No need to pass these fields - Null? | The pagination requirements for the GetDataHolderBrands endpoint are aligned to the Consumer Data Standards. I've extracted the requirements here:Query Parameters The consumer will stipulate pagination requirements on the request using query parameters. When paging is supported the consumer MAY provide the following query parameters: page – the page number being requested (with the first page being 1) page-size – the number of records to return in each page If the query parameters are not provided the following defaults will be assumed: page – a default of 1 (the first page) will be assumed page-size – a default of 25 will be assumed None of these fields are compulsory and the page-size default is 25. |
| 722 | In a CTS, as part of collection arrangement, how to we get access to the DH sandbox? Is it always going to be a simulated DH? Or can we (as a provider in a principal-provider collection arrangement) also get access to the the real DH sandbox environments for CTS? | As the Provider in a collection arrangement you will impersonate the Principal in order to test your platform configured for their software product. This article explains https://cdr-support.zendesk.com/hc/en-us/articles/900003114503-Collection-Arrangement You will work with the Principal to test their software product integrated with your platform. The principal will be first contact with the CTS team but there is nothing stopping them involving you in the testing process. Population of the various brands and software products on RAAP has been covered in my response to your ticket #668. |
| 725 | Can you clarify if the process to authenticate the DH is the same as the DR? Will the DH present a private_key_jwt to authenticate? Where the client_id identifies the DH to ACCC. # Decoded client assertion JWT {"alg": "PS256","typ": "JWT","kid": "12456"}{"iss": "12345","sub": "12345","iat": 516239022,"exp": 1516239322,"aud": "https://www.holder.com.au/token","jti": "37747cd1-c105-4569-9f75-4adf28b73e31"} |
Currently there are no CDR Register hosted authenticated APIs that data holders are authorised to consume. If this changes in the future, the CDR Register Design will be updated to reflect this requirement. |
| 744 | Do DHs must support amending of expired/revoked consents? | Technically consents cannot be amended. Consents can only be revoked or a new consent created linked to a previous revoked consent via a common arrangement ID. Data Holders must support consent expiry and revocation as per the rules and the standards. |
| 751 | I am looking for guidance on how to deal with some edge cases when it comes to outage publishing and availability metrics calculations by data holders in the context of manual publishing. That is a person updates a dashboard manually with outage information and that information is published in the Get Status or Get Outage APIs or used for availability metrics calculations. Is it correct to assume that: 1. Availability metrics cannot be changed after sharing them? For example we recorded an unplanned outage on 30th of June, between 1pm-6pm = 5 hours of down time. This down time was considered in the metrics used for the June and shared with ACCC on for example 2nd of July. On 4th July we become aware the outage was only happening for 3 hours. ACCC asks for availability metrics on 6th of July? The June availability will still include the 5 hours to keep the same numbers as previously reported, even if not accurate? 2. There must not be any discrepancies between what was published to CDR participants and what is used to calculate availability metrics even if technically incorrect. For example we publish via the Get Status API that an unplanned outage started at 1pm with a resolution time of 5pm on a certain day. The outage is in reality fixed by 3pm but no one has updated the outage notification and we continue to show via the Get Status API that the service is down until 5 pm. For availability calculations we will use the time we were telling the CDR participants that the service is down (4 hours) and not the time the outage actually lasted for (2 hours) 3. An unplanned outage can be used for calculation of the availability metrics even if it was not reported to the market while it was happening. For example we had an outage between 1:30-pm-2pm. We were unable to report the outage via the Status API while it was happening. However for availability metrics calculations we will consider the 30 minutes as down time 4. An unplanned outage's resolution time can be modified as long as the outage is in progress 5. An unplanned outage's resolution time as presented in the Get Status API cannot be modified once that time has passed. For example the initial outage was estimating the resolution time as 3pm. The outage continued past 3 pm but due to human error the outage notification was not updated. It is now 4pm and the outage is still ongoing. We cannot change the resolution time of the original incident published via Get Status API, but can create a new outage with start time of 3pm. Both outages will be considered as down time for availability metrics calculation purposes. 6. An unplanned outage's detection time as presented in the Get Status API cannot change once published even if the outage is in progress or resolved. For example: - we reported the detection time as 1pm but later realized that the outage actually started at 12pm. It is now 2pm, the outage is ongoing but detection time is still kept as 1pm. The extra hour of outage will be reported as a separate outage and included in the availability metrics calculations even if the CDR participants were not able to see it via the Get Status API - we reported the detection time as 1pm. It is now 3pm, the outage is fixed but became aware that the outage started at 12pm. The start time of the outage will be kept as 1pm and a new outage will be reported for the extra hour between 12pm-1pm for availability metrics calculation purposes. 7. Changes to planned outages that happen more than 7 days before the outage start date are ok? For example we could publish an outage for next week, but decide to change the date for the week after. We stop publish info about the next week outage and start publishing info about the outage in two weeks. 8. Changes to future planned outages are ok even if happening within the 7 days window before the outage starts? For example we report that a planned outage will take from 1pm to 4pm but 4 days before the initially reported start: - we change to 1pm-3pm OR - we change to 12pm-3pm OR - we change the date and time all together to an earlier or later date 9. Once started a planned outage cannot be changed to ensure consistency, even if the end time will be earlier than anticipated. For example we reported a planned outage from 1pm to 4pm and at 2pm the outage is finished. However our Get status & get outage APIs will continue to publish that the system is down | Q: Availability metrics cannot be changed after sharing them? For example we recorded an unplanned outage on 30th of June, between 1pm-6pm = 5 hours of down time. This down time was considered in the metrics used for the June and shared with ACCC on for example 2nd of July. On 4th July we become aware the outage was only happening for 3 hours. ACCC asks for availability metrics on 6th of July? The June availability will still include the 5 hours to keep the same numbers as previously reported, even if not accurate? A: There is nothing in the rules or standards indicating that you can't change previous metrics on subsequent calls if they were previously reported incorrectly. The most accurate metrics would be preferred. If there is substantial change over time you may want to let the ACCC know and provide reasons but that is up to you as a data holder. Q: There must not be any discrepancies between what was published to CDR participants and what is used to calculate availability metrics even if technically incorrect. For example we publish via the Get Status API that an unplanned outage started at 1pm with a resolution time of 5pm on a certain day. The outage is in reality fixed by 3pm but no one has updated the outage notification and we continue to show via the Get Status API that the service is down until 5 pm. For availability calculations we will use the time we were telling the CDR participants that the service is down (4 hours) and not the time the outage actually lasted for (2 hours) A: There may be some confusion here. The availability metrics should articulate unplanned unavailability. The purpose of the planned outage API is to provide a mechanism where you can communicate a planned outage and then exclude the outage associated with the planned event from your availability numbers. Q: An unplanned outage can be used for calculation of the availability metrics even if it was not reported to the market while it was happening. For example we had an outage between 1:30-pm-2pm. We were unable to report the outage via the Status API while it was happening. However for availability metrics calculations we will consider the 30 minutes as down time A: Yes, of course. An unplanned outage should still impact the availability metric even if it wasn't detected or reported immediately Q: An unplanned outage's resolution time can be modified as long as the outage is in progress A: Assuming you mean in the status API response then yes. In fact this should be considered best practice. Q: An unplanned outage's resolution time as presented in the Get Status API cannot be modified once that time has passed. For example the initial outage was estimating the resolution time as 3pm. The outage continued past 3 pm but due to human error the outage notification was not updated. It is now 4pm and the outage is still ongoing. We cannot change the resolution time of the original incident published via Get Status API, but can create a new outage with start time of 3pm. Both outages will be considered as down time for availability metrics calculation purposes. A: There is nothing saying you can't update the messages coming from the status API (as stated above this is expected). The messages provided in the status API should not influence the reporting of availability (which should be an objective statement of unplanned outage). Q: An unplanned outage's detection time as presented in the Get Status API cannot change once published even if the outage is in progress or resolved. For example: - we reported the detection time as 1pm but later realized that the outage actually started at 12pm. It is now 2pm, the outage is ongoing but detection time is still kept as 1pm. The extra hour of outage will be reported as a separate outage and included in the availability metrics calculations even if the CDR participants were not able to see it via the Get Status API - we reported the detection time as 1pm. It is now 3pm, the outage is fixed but became aware that the outage started at 12pm. The start time of the outage will be kept as 1pm and a new outage will be reported for the extra hour between 12pm-1pm for availability metrics calculation purposes. A: Yes it can. The message in the status API should reflect the current understanding of the issue to keep the community informed. Q: Changes to planned outages that happen more than 7 days before the outage start date are ok? For example we could publish an outage for next week, but decide to change the date for the week after. We stop publish info about the next week outage and start publishing info about the outage in two weeks. A: The statements governing correct reporting of planned outages are that they should be: Commensurate in length and frequency to other primary digital channels offered by the data holder, Published to data recipients with at least one week lead time for normal outages, May occur without notification if the change is to resolve a critical service or security issue.Q: Changes to future planned outages are ok even if happening within the 7 days window before the outage starts? For example we report that a planned outage will take from 1pm to 4pm but 4 days before the initially reported start: - we change to 1pm-3pm OR - we change to 12pm-3pm OR - we change the date and time all together to an earlier or later date A: If you change it to an earlier date that means that one week notice is no longer the case then you would be non-compliant with the statements in the standards. Otherwise, fine. Q: Once started a planned outage cannot be changed to ensure consistency, even if the end time will be earlier than anticipated. For example we reported a planned outage from 1pm to 4pm and at 2pm the outage is finished. However our Get status & get outage APIs will continue to publish that the system is down A: Sure it can |
| 756 | One of the Schedule 2 Part 2 controls is "Restrict administrative privileges: Administrative privileges are granted only on an as needs basis for users to perform their duties and only for the period they are required for. Privileges granted on an ongoing basis are regularly reviewed to confirm their ongoing need." The CDR - Accreditation controls guidance (https://www.accc.gov.au/system/files/CDR%20-%20Accreditation%20controls%20guidance.xlsx) states "2) administrative privileges are limited to a small number of personnel on an ongoing basis. Administrative access rights is reviewed on a regular basis, at least monthly." Is the review of administrative rights required to be at least monthly or can this be reduced to less frequent e.g. annually? | The guidance we publish sets out our expectations or best practice. In this case for review of administrative access rights we consider review on a regular basis should be at least monthly. |
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 |