-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (27th of May 2021)
CDR API Stream edited this page May 27, 2021
·
5 revisions
When: Weekly every Thursday at 3pm-4.30pm AEST
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
- 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 contact@consumerdatastandards.gov.au 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.9.0 Published | Link to change log here |
| Standards | Version 1.10.0 Drafted | Link to Version Project Board here |
| Maintenance | 7th Maintenance Iteration underway | Agenda of the backlog session |
| Maintenance | Decision Proposal 178 - Banking Maintenance Iteration 7 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| TSY Newsletter | 27th of May 2021 Edition | View in browser here |
| DSB Newsletter | 21st of May 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 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 180 - Energy Draft Feedback Cycle 3 | Link to consultation |
| Consultation | Decision Proposal 182 - InfoSec Uplift for Write | Link to consultation](https://github.com/ConsumerDataStandardsAustralia/standards/issues/182) |
| Consultation | Decision Proposal 183 - Purpose Based Consents | Link to consultation](https://github.com/ConsumerDataStandardsAustralia/standards/issues/183) |
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 |
None 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: #169517
| Ticket # | Question | Answer |
|---|---|---|
| 558 | If DHs have received exemptions (how would the ADRs know) and handle the differences between the various Data Holders? (e.g if Some Scheduled Payments are not returned by a Data Holder and the ADR is ignorant about the same and provides incorrect recommendations) | Exemptions are published on the CDR Exemptions Register managed by the ACCC. This can be found at: https://www.accc.gov.au/public-registers/consumer-data-right-exemptions-register#:~:text=The%20ACCC%20may%20exempt%20a,and%20the%20consumer%20data%20rules. The ability to detect the support for various exemptions is highly dependent on what the exemption is. To date exemptions have mainly been to the implementation of specific aspects of the rules or standards that already have discovery mechanisms such as support for specific account types or the implementation of PAR. |
| 559 | There a number of specific HTTP Response types as defined which can be used when makes an incorrect API request. Further extension to standardization In regards to Reporting - do the specific HTTP Response Codes need to be included in the reporting as well? | In relation to reporting under rule 9.4, data holders are required to state the number of times they have refused to disclose CDR data and also set out each of the CDR rules or data standards they relied upon to refuse disclosure of that data. Under the current data standards, where a data holder has refused to disclose CDR data in reliance on a data standard, it is expected that they will include the relevant HTTP response code set out in the standards. When the standards are updated to incorporate the standardised error codes, it will be expected that any relevant error code set out in the standards be included in the data holder’s report as applicable. |
| 707 | If a Data holder introduces a captcha along with the text field for OTP is that considered compliant. The current CX guidelines does not talk about Captcha. Would like to see if there are any guidelines about captcha in general from CX perspective. |
This would come under the banner of "additional friction" and is prohibited by the rules. It would not be deemed acceptable. If there are specific drivers for this being included in the flow they should be raised in standards maintenance along with the specific risk factor or attack vector that the Captcha is being used to address. If there are security concerns we will seek to address them in the information security profile for all data holders and consumers. At this stage we believe that the risks that are normally mitigated by a Captcha are already addressed by other controls so the inclusion of a Captcha would be spurious and deleterious to consumer experience. |
| 642 Part 2 | Can you please clarify if GetMetrics will be a test scenario that all participants have to pass? And if that is the case, if an ADI passes CTS this week, will it mean they will have to re-test when GetMetrics becomes available for testing in May/June? |
GetMetrics is not a test scenario that participants have to pass as a condition of meeting the CTS requirements. However, once an ADI has gone-live, the CDR Register will begin calling the GetMetrics endpoint. If there are issues with this call then this will be a compliance issue. We will work with you to address it. I will re-stress the point that the expectation remains that participants build the GetMetrics endpoint aligned to the specification and conduct their own testing to ensure it is valid. |
| 747 | Are there any anticipated/forthcoming updates to the DH consumer dashboard CX as a result of DP 144? E.g. will it be a requirement to signal a consent as having been amended? (i.e. new status type? In-channel notification?) Or will this be at the discretion of the DH? |
Rule 4.27 requires DH dashboards to be updated to reflect changes, but this does not imply the use of a new 'status' or notification for amended authorisations. DP144 refers to changes being signified in the authorisation flow but does not require these same changes to be signified in DH dashboards. The new amending authorisation artefacts recommend a DH-provided CDR receipt that reflects these changes. The updated DH dashboard artefacts are silent on this aspect and leave it to DH discretion. |
| 777 | - from July 2021 we would need to accept any notification from a Data Recipient for a Consent Amendment, as per CDR Rule 4.18C (2)(a), and subsequently invite the member to amend their Authorisation, as per CDR Rule 4.22A. - Our solution for allowing a member to amend their Authorisation will need to comply with rules 4.23 & 4.24 (and from a member’s perspective the process may be identical to the New Consent/Authorisation process). - Technically our solution is required to update an existing data sharing arrangement record rather than create a new record when notified of a Consent Amendment. - From November 2021, the Consent Amendment CX Standards must be incorporated into our solution for processing Consent/Authorisation Amendments, and the member will experience a different process to the New Consent/Authorisation process. Could you please assist with advising if our interpretation is compliant with the CDR Rules and the Standards. Our question is: - If a Data Holder is planning on implementing the CX Standards re. Consent Amendment in the November 2021 release, are they still expected to comply with Rules 4.22, 4.22A, 4.23 & 4.24 specifically for Consent Amendment from the July 2021 release date onwards? |
We often need to consult with other agencies (such as Treasury and ACCC) before replying to rules queries, but endeavour to tend to these queries as quickly as we can. Question: If a Data Holder is planning on implementing the CX Standards re. Consent Amendment in the November 2021 release, are they still expected to comply with Rules 4.22, 4.22A, 4.23 & 4.24 specifically for Consent Amendment from the July 2021 release date onwards? Yes. I can confirm that the other interpretations in your query are also correct, but note the following: The amending authorisation standards only apply if the ADR provides the cdr_arrangement_id The cdr_arrangement_id establishes a link between the current and previous authorisations that can be used to implement the amending authorisations standards. Technically, when an authorisation is amended the existing authorisation is revoked and a new authorisation is established, even where the cdr_arrangement_id is provided by the ADR. |
| 782 | Consider the following scenario. Jack and Jill are joint borrowers for their home loan, which allows them to have multiple offset accounts. a. Jack has an Everyday account and he is the sole account owner. b. Jill has a Prime Access account for which she is the sole account owner. c. Jack and Jill are joint account owners for a Platinum Plus account. d. All three of their eligible accounts are offset against their home loan. 1. When Jack decides to authorise Open Banking data sharing for his accounts, he will be able to see his Everyday Account and the Platinum Plus account he jointly owns with Jill. a. He will not see Jill’s Prime Access account because he is not the account holder and has no account privileges (he is not able to transact on the account). 2. Similarly, when Jill decides to authorise Open Banking data sharing for her accounts, she will be able to see her Prime Access account and the Platinum Plus account she jointly owns with Jack. a. She will not see Jack’s Everyday account because she is not the account holder and has no account privileges (she is not able to transact on the account). |
In response to your submission, there did not appear to be a question so I am inferring that you are seeking to understand if your interpretation of the hypothetical scenario you have raised is correct. If that is the case then the answer is yes based on the information you have provided. What isn't clear from the scenario is whether Jack and Jill have visibility of each others accounts in existing digital channels. If they don't have visibility in existing channels then the answer is yes. If they do have visibility (even if they don't have ownership) we would expect the accounts to be visible but only shareable with permission. |
| 787 | Section 4.7 in the rules states that a data holder may, in certain circumstances: - refuse to ask for an authorisation in relation to the relevant CDR data, or - refuse to disclose required consumer data in response to the request to prevent harm. For the 2nd scenario (refuse to disclose), we (the data holder) send a '403 Forbidden' response to the ADR, as per the data standards. However, for the 1st scenario (refuse to ask for an authorisation), we are NOT currently sending any response to the ADR. Following is what is currently happening in this scenario: 1. Consumer gives a consent to an ADR, who then redirects the consumer to our authorisation website. 2. Once the consumer lands on our authorisation website we ask them to enter their member number. 3. Our system then checks the member number to see if this member is permitted to authorise data sharing. 4. If we have disabled sharing for this member number (e.g. to prevent harm or abuse), our authorisation website will then instruct the member to login to Internet Banking. 5. Once the member has logged into Internet Banking, it displays a message informing them that sharing has disabled for them and that they can contact us (the dataholder) for more information. Can you please advise if the above process for the 'refuse to ask for an authorisation' scenario complies with the CDR Rules/Standards? |
In response to your question. The flow described does not fully implement the normative standards. The expectation is that the completion of the flow would result in a redirect back to the ADR with an indication that the authorisation has been rejected (see https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthError). Asking the user to log into Internet Banking for further information as to why sharing is being refused would be acceptable but the ADR still needs to be informed. Note that any refusal of this nature would need to be reported to the regulatory with an explanation of why the refusal occurred and would also need to be reported via the metrics end point. |
| 789 | Seeking clarification of the response for the /UserInfo endpoint. The specification says: The requirements for the UserInfo End Point are specified in section 5.3 of [OIDC]. Data Holders MUST support a UserInfo End Point. Section 5.3 For privacy reasons, OpenID Providers MAY elect to not return values for some requested Claims. Which claim other than "sub" is mandatory? Assuming first and last name are to be included, do the values in the response need to be captured at the time of consent creation or can be fetched in real-time. For example, your last name may change (due to marriage) from time of consent to current. |
Q: Which claim other than "sub" is mandatory? A: If not otherwise specified in the standards then the normative standard should be referred to. Q: Assuming first and last name are to be included, do the values in the response need to be captured at the time of consent creation or can be fetched in real-time. For example, your last name may change (due to marriage) from time of consent to current. A: They should be fetched in real time |
| 796 | At the end of the Payload Conventions section - https://consumerdatastandardsaustralia.github.io/standards/#payload-conventions the standards state - Optional fields If the field is optional a null value or empty field response is accepted. For an optional field like 'overviewUri' which should be of the URIString format, should an empty string value like "" be considered compliant? The explanation for Empty/Null Fields states - An empty field (ie. a field that is not present in a payload) will be considered equivalent with a field that is present with a null value. An empty string (“”) is not considered to be equivalent to null. |
Thanks for picking this up. This text should have been removed once the optionality section, which is much more specific, was added. We will fix this as a defect in v1.10.0 |
| 807 | We have a question we would like to clarify: In the event the ADR fails to obtain an Access or Refresh Token within the allocated Authorisation Code expiry period, what is the expectation on the Data Holder? 1. When presenting this consent authorisation in the Customer Dashboard? i.e. would we need to show it as Inactive or can we not show it at all since its technically incomplete? 2. Is there anything else that Data Holders are expected to do in this scenario, or is the owners on the ADR to start a new consent authorisation request? We are just worried that in this scenario it will be very difficult to explain to the Customer why their consent authorisation has failed. |
this is currently at the discretion of the Data Holder. Where the Authorisation Code has not been successfully exchanged for access/refresh token, the consumer will have given authorisation (hence the DH has issued an Authorisation Code) however there will no longer be a way for the ADR to access the orphaned authorisation. There have been change requests related to this raised on Standards Maintenance (for example, https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/219 and https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/175) and addressing this issue is on our radar. That said, presently a Data Holder must decide how they will handle this but it would not be considered an authorisation that could be enacted. If you can identify these scenarios and provide an explanation to the consumer explaining the issue, this would obviously help them to attempt to re-establish consent. |
| 748 | Question 1 Is the working principle that only the ADR Client metadata acknowledged as modifiable in the CDS SSA Definition section can only be changed by the ADR? Question 2 Is the working principle that previous values provided in the Registration Request Claims cannot be modified by the ADR? Question 3 The optional “legal_entity_name” claim to be introduced from 1 July 2021 is not listed as modifiable. Accordingly, if an ADR’s legal_entity_name changes in the future is the principle that a new Software Product must be registered with the new details? |
|
| 799 | Presently working with team on PRD. I've reviewed but can't seem to locate any UX guide on PRD. Are there any available? | The CX Guidelines only relate to consumer data; we have not produced equivalent guides for PRD as they are out of scope for the CX Working Group. There is a product comparator demo here which was put together by the technical working group, but this is purely for demonstrative purposes. |
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 |