-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (25th of February 2021)
CDR API Stream edited this page Jun 8, 2021
·
6 revisions
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
- 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.6.0 Published | Link to change log here |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changes here |
| Maintenance | 6th Maintenance Iteration planned for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to contact@consumerdatastandards.gov.au |
| Maintenance | 6th Maintenance Iteration Voting | On the 6th Maintenance Iteration vote on the scopehere |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 19th of February 2021 Edition | View in browser here |
| DSB Newsletter | 19th of February 2021 Edition | View in browser here |
| Consultations | Decision Proposal 158 - Participant capability discovery This decision proposal pertains to the consultation for a functional discovery mechanism pertaining to the DSB's Future Plan roadmap item published here: ConsumerDataStandardsAustralia/future-plan#5. Feedback is now open for this proposal. Feedback is planned to be closed on 5th March 2021. |
Link to consultation |
| Consultations | Decision Proposal 159 - v1.7.0 Placeholder for the 1.7.0 Release |
Link to consultation |
| 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 |
| Workshop | DSB - Joint Account Workshop (Online) Time: 2nd of March 1pm - 5pm AEDT Objectives: To facilitate knowledge sharing on the topic of Joint Accounts(JA) To collect feedback on JA CX Guidelines, scenarios, the JA proposals from Noting Paper 157, and any related commentary To highlight any other issues or scenarios that warrant consideration |
Register here |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Rules | Andrew Breeze |
| ACCC | CDR Register (Technical) | Ivan Hosgood & Elizabeth Arnold |
| ACCC | Onboarding | Emma Joy & Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
The ACCC will deliver a scenario-based presentation on the implementation of the joint account rules. The presentation will utilise wireframes prepared by the DSB to provide examples of how we expect some of the requirements in version 2 of the CDR rules to apply in practice, in particular the in-flow election requirement and how consumers can stop data sharing on a joint account. The presentation is intended to supplement the guidance on joint account implementation published by the ACCC on 19 February 2021.
Today's presentation will walk through an interactive MIRO Board here
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:
| Ticket # | Question | Answer |
|---|---|---|
| 257 | In the rules (for example Part 4, Division 4.4 (Rule 4.25)) it outlines where authorisation is withdrawn a DH must be able to provide notifications to ADR's in accordance with the data standards How does the data standards envision these notifications to occur when there is no PUSH's allowances within the APIs? |
The mechanism for communication consent withdrawal to an ADR when revocation occurs on a DH dashboard is to call the "CDR Arrangement Revocation End Point" hosted by the ADR. This is documented in the standards in the InfoSec Endpoints Section. CDR Support Portal Article |
| 389 | In the case of Collection Arrangement, if a Provider is nominated by multiple Principals. The Provider will have one certificate of its own. So, would it be correct to say that the Provider's certificate can be used for all the Principals for making API calls to data holders requiring TLS? | Each Principal must have a client certificate issued to it, which the Provider will use to request CDR data on the Principal's behalf. One security mechanism which is available to the ACCC and the ADRs is to be able to revoke a certificate, based on security hygiene processes or suspected/realised unauthorised disclosure of the private key. To contain the impact of this revocation, the client certificate used to collect CDR data MUST be used exclusively for the Principal it belongs to. CDR Support Portal Article |
| 488 | So given a Local Entity, without being a subsidiary of the Foreign Entity, can combine with them to potentially become an ADR and participate in CDR, are there any specific requirements/certifications (eg. monetary, insurance, security, IT, etc) that the Local Entity must comply with participate? | Having a local agent is essentially a requirement of the rules to ensure that any foreign entity wishing to become accredited has an address for service in Australia. A local agent otherwise would not be able to participate in the CDR (for example by collecting or using CDR data itself) unless it was either a) accredited in its own right; or b) an outsourced service provider to a person who was accredited. Outsourced service providers are covered by Rule 1.10 of the CDR Rules. CDR Support Portal Article |
| 522 | Hi there, just wondering if we are required to send OTP to international phone numbers in the user identifier consent screen for Data Holders? Or are we only required to send them to Australian mobile numbers? | The relevant sections of the standards relating to this question are: Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page The delivery mechanism for the OTP is at the discretion of the Data Holder but MUST align to existing and preferred channels for the customer and MUST NOT introduce unwarranted friction into the authentication process Based on these statements there is no requirement to use SMS for this OTP. The OTP is required to be delivered via an existing mechanism and not introduce additional friction but is otherwise at the discretion of the data holder. CDR Support Portal Article |
| 541 | As a part of Division 9.3-Section 9.5 Requests from CDR consumers for copies of records, A data holder on receiving a request for copies of certain records must provide a report to the CDR Consumer. For the complaints records requested under this rule, Could you please clarify: 1) the Complaints data details expected to be shared by the data holder to the consumer in the report. 2) A previous article https://cdr-support.zendesk.com/hc/en-us/articles/900002708306-Consumer-access-to-copies-of-records mentions the information to be captured by a Data Holder when dealing with a copies of records request by a customer, Are the same data details expected to be shared in the report. |
As you set out in your email, rule 9.5 allows a CDR consumer to request from a data holder copies of records relating to particular information that relates to the CDR Consumer, including ‘CDR complaint data’ records. Rule 9.3(1)(f) requires a data holder to maintain ‘CDR complaint data’ records, and ‘CDR complaint data’ is defined in rule 1.7 of the Rules. CDR complaint data is statistical information about complaints rather than records of complaints themselves. For this reason, when a data holder receives such a request under rule 9.5, it does not need to provide a copy of the complaint itself. However, a data holder will be required to provide copies of records relating to CDR complaint data as it relates to the CDR consumer. Such records should include the details for each of the relevant items set out in the ‘CDR complaint data’ definition in rule 1.7. The previous article you included as a link in your email provides one example of what form these records may take when they are provided to the CDR consumer in response to a request (e.g. relevant complaint logs as they relate to the CDR consumer). CDR Support Portal Article |
| 549 | I was looking back through open tickets and couldn't find the answer to the following, even though it was marked as Answered: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/223 I was hoping the answer could be posted on the issue for traceability so that we could close the ticket. |
this may have been an error during review of the backlog. The DSB has previously given guidance that accounts that fall into grey areas between the categories defined we leave the selection of category entirely up to the discretion of the Data Holders. If you feel a change to the standards is warranted, please feel free to create a change request. |
| 561 | I’ve been going through the minutes of the CDRIC from the 28/1 looking to find the answer to a question that was raised in the chat about the format that the Reg Reporting Form needed to be submitted in but they haven’t been updated yet. I believe the answer was to the tunes of: ‘It must be emailed in excel format but if a Data Holder’s internal security policy requested that it be delivered in another format like pdf, then it may be emailed in both excel and pdf.’ |
Thanks for the question, yes on the CDR Implementation Call on the 28th of January 2021 we did cover off and answer the question of: "Reporting Form due for submission tomorrow... Does the ACCC require the report (completed in excel) to be emailed as an excel also? or should it be emailed as a PDF?". The answer provided was: "Yes, a Data Holder may submit an additional format of the report if required by the Data Holder. However, the expectation that the excel format, as defined on the ACCC website: https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/reporting-forms-rule-94#:~:text=Consumer%20data%20right%20(CDR)&text=Reports%20to%20the%20ACCC%20must,%40oaic.gov.au. is submitted at a minimum as per the website requirements. CDR Support Portal Article |
| 564 | If a consumer decides to cancel during the authentication process, do you need to redirect them back to the 3rd party app or is it okay to show a set up cancelled screen instructing them to go back to the app themselves without automatically redirecting them? | The standards defer to the normative standards for this. In particular OIDC core defines this behaviour in section 3.1.2.6. <br. In summary, the standards state that the DH (authorisation server) would respond to the ADR (client) with an error outcome. CDR Support Portal Article |
| 565 | As per ACCC’s guideline on Data Recipient unavailability (https://cdr-register.github.io/register/#certificate-authority-unavailable), Data Holder should follow either long term back-off pattern or short term back-off pattern if ADR is not available. First two retry wait time in long-term are 200 milliseconds and 400 milliseconds. These initial retry wait time may not be relevant from real world perspective as the gap between consecutive retry is in milliseconds. Also, 7 days duration (as per long term pattern) is too long and 10 minutes (as per short term pattern) is too short for a live application recovery point of view. Considering these above-mentioned points and to provide a better customer experience, can retry mechanism (in case Data Recipient is unavailable) be implemented as a combination of both short-term and long-term back-off pattern? Where Data Holder will start with short-term pattern (once in every minute for 10 minute or until recovery) followed by an exponential pattern like below Number of Retry Wait Time (in minute) 1 20 2 40 3 80 4 160 Till 3 days |
The back-off patterns currently defined help data holders meet the intent of the rules but there is potential opportunity for improvement. A standards-maintenance GitHub issue has been raised to track this work: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/367 as the back-off pattern isn't the only mechanism which could be used to mitigate against consents losing synchronisation between participants. In the interest of community collaboration, I'd encourage you to discuss how the current model can be improved on this GitHub maintenance issue. CDR Support Portal Article |
| 566 | Often customer have two or more home loan accounts for the same security (property), for example part of the loan is fixed rate and another part is variable rate, and those loans will be treated as separate accounts/products. Most of the home loan fees are charged per security, not for each individual home loan account, whilst there are some fees that are charged per a loan account. Can you please provide guidance, in the current GetAccountDetails API ‘Fees’ object, is there a way to show fees for a home loan that are charged not per loan account, but for security? For example in a scenario when a customer has 2 loan accounts: Fixed rate product and Variable rate product, Discharge fee will be paid per security (property), so it will be incorrect to indicate that discharge fee is applicable to both home loan accounts, but also incorrect to show it’s applicable to only one of customer’s accounts. Please let us know how to display Discharge fee in this scenario. | This is the purpose of the additionalInfo field. You would provide descriptive text describing this situation in the additionalInfo (or a link to the detail in additionalInfoUri) for the fee in each account. CDR Support Portal Article |
| 568 | Our source system does not capture time components for some fields. In these cases we are adopting an approach to use "00:00:00" as the time component for those fields consistently. This leads to the following situation where we have a date/time field of "2020-12-24T00:00:00" (which is in Adelaide time). But according to the CDR guidelines, it should offset relative to UTC, so that would mean "2020-12-23T13:30:00+00:00" Can you please confirm that this is correct? It seems funny that the date has changed from the 24th (Adelaide Time) to the 23rd (UTC). In reality it is still the same date/time, but our developers would like confirmation that this approach is fine. |
In relation to your question regarding dates and time. While the scenario you describe is at the discretion of the data holder the approach you are using would be considered appropriate. CDR Support Portal Article |
| 577 | As per the CDR website – APCA number is an optional value to be returned by the Get transactions for account API. The understanding is that if the data is held then an optional field becomes mandatory to provide in the Open Banking API responses. Investigations have found the APCA number is received in the inbound file for direct entry transactions and it is used for processing but it is not stored in a database. Therefore the APCA number is not part of the transaction data. Given this is an optional field and the data is not held as part of the transaction, please confirm if APCA is still an optional value in this instance. |
An optional field indicates that a response will be valid if the field is not supplied but it is still required that the data be shared if held. In this case apcaNumber is labelled as optional and it would appear that you are not holding the data. In this case it would be valid to respond without the apcaNumber field populated. CDR Support Portal Article |
| 580 | Could you please confirm that accounts that are not eligible should not be shown at all in the authorisation flow in the account selection section? That is they should not be included in the unavailable section. | That is correct. The CX Standard allowing DHs to show unavailable accounts applies strictly to eligible accounts. Ineligible accounts should not be shown in the authorisation flow as per the rules on eligible consumers and required consumer data. |
| 584 | Are there any provisions to allow a Data Holder to request ADRs to resubmit PAR request for existing arrangements to allow ID permanence IDs to be regenerated? For example, suppose we have used a cypher technique to create our ID Permanence IDs, This cypher technique uses the cdr_arrangement_id as a 'key' when producing the ID permanence translation. If a situation occurs and we need to modify our cypher, it would be beneficial for us to be able to request all ADRs submit PAR requests so that we can give them the new ID permanence IDs for their existing arrangements. We are unable to see any place in the standards where this is made possible. This leaves us in the position where we would need to potentially support multiple cypher's such that we could continue to handle ID Permanence IDs held by ADRs using the old cypher. |
Relating to your question regarding ID permanence, I'm afraid keying ID permanence on the arrangement ID would not be a compliant approach. The key statement in the standards that would be relevant here is in the ID permanence section: IDs MUST be immutable across sessions and consents but MUST NOT be transferable across data recipients. For example, data recipient A obtaining an account ID would get a different result from data recipient B obtaining the ID for the same account even if the same customer authorised the access. Under this constraint IDs cannot be usefully transferred between client organisations or data holders. Note the bolded section of this statement. The requirement of the standards if that the same account is shared under two different arrangements for the same subject then the same ID must be provided. Keying the ID cipher on the subject or a combination of subject and ADR client ID would be more appropriate. This would also obviate the need for a change to PAR as you describe in your question. CDR Support Portal Article |
| 586 | We are seeking clarification regarding the accountId property in the BankingScheduledPaymentTo schema. In a previous CDR Support Portal response (https://cdr-support.zendesk.com/hc/en-us/articles/900005246743-BankingScheduledPaymentTo-toUType-property), the following guidance was given: “Use accountId if the payment is to a shared account, held by the current customer, and one of the account scopes is included in the consent.” Does the phase ‘shared account’ mean use of the accountID property is limited to when a payment is to a joint account, or are we correct to also provide the accountID property when a customer is making a payment to an account where they are the sole account holder, assuming this account is accessible under the current consent granted by the customer? |
in that answer, the context of "shared account" was meant to mean the customer has selected that account for sharing. Whether the account is a joint account or held by a single customer does not matter. Note however that two different joint account holders will have different accountIds for the same account according to the ID Permanence requirements because the accountId is within the bounded context of the customer (subject). |
| 589 | I have a question relating to Active Token for the Expired Consent. The ADR will receive one Active Token and Refresh Token when a consent is successfully granted. In the case if a consent is expired; I understand the refresh token will be expired as well, as the Refresh Token MUST NOT exceed the end of the duration of sharing consented to by the Consumer. I am seeking for the answer what is the expected behaviour of the Active Token when a consent is expired? During my testing, I set up a 7 mins consent, and the Active Token is 5 mins; so within the 7 mins when the consent is active, I am able to Refresh the token for next 5 mins, and Trigger API calls, as expected. On the 7 mins, the consent is expired, in the case if I don't refresh the token. I will still be able to make CDR API calls until the active token is expired, then I received 401 invalid token message. Is this acceptable? or we are expecting once the consent is expired, the Active Token should be become inactive immediately? |
I assume your question is related to the management of the Access Token, rather than Active Token, when the authorised consent to collect expires. If I have misunderstood let me know as my answer may not make sense. The standards do not specifically require an access token to become invalid when a consent expires. This is because it is valid to request a consent with a zero second duration specifically for once off collection. As a balance we require access tokens to have a short life span. The expectation would be that no new access tokens should be created once consent has expired but existing access tokens should be honoured. CDR Support Portal Article |
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.
| Ticket # | Question | Answer |
|---|---|---|
| # | Question | Answer/ Action |
|---|---|---|
| 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 |