ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (8th of July 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (8th of July 2021)

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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.11.0 Published Link to change log here
Standards Version 1.11.0+ Stay tune - next version being planned
Maintenance 8th Maintenance Iteration Planned Invitations to come for the 14th of July 2021
Maintenance Decision Proposal 202 - Banking Maintenance Iteration 8 Link to consultation
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 1st of July 2021 View in browser here
DSB Newsletter 2nd of July 2021 View in browser here
Consultation Decision Proposal 180 - Energy Draft Feedback Cycle 3 Link to consultation
Consultation Decision Proposal 182 - InfoSec Uplift for Write Link to consultation
Consultation Decision Proposal 183 - Purpose Based Consents Link to consultation
Consultation Decision Proposal 186 - Engineering Support Link to consultation
Consultation Decision Proposal 191 - Retailer to AEMO InfoSec Profile Link to consultation
Consultation Decision Proposal 200 - Action Initiation Framework Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Workshop DSB & TSY 27th of July - Action Initiation Eventbrite Registration Link

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 Jonathon Ingle
DSB CX Standards Eunice Ching
DSB Technical Standards - Banking James Bligh
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None 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
835 - Part 2 Could you clarify the points below also? data holder can reject the invocations under the NFRs of they choose to. 1. Are you also suggesting to apply the policy during API invocations as we have mentioned earlier? Not during the issuing of access tokens. Bearing in mind that sessions are short lived the reality is that there is unlikely to be mixed traffic types for a single session. 2. Although the chance is very unlikely, there's no restriction to use a single token to do both attended and unattended API invocations. In such a situation, how should we treat the incoming request? In response to your first question, when the access token is issued it is not possible to know if the session is attended or unattended. Once the traffic is received the determination can be made and should be applied to the session at that point. In response to your second question, the reason for the two types of access is to allow for differentiated quality of service for when the customer is interactively using a service or not. In that context if some traffic is attended and some isn't it would probably be better to treat the session as attended. That would avoid you accidentally giving poor service to your customer. The standards are not explicit on this point, however.
885 1.) Does the accountID under BankingScheduledPaymentTo Need to follow ID permanence rules? 2.) Does the accountID under BankingScheduledPaymentFrom Need to follow the ID permanence rules? In response to your two questions: 1.) Does the accountID under BankingScheduledPaymentTo Need to follow ID permanence rules? 2.) Does the accountID under BankingScheduledPaymentFrom Need to follow the ID permanence rules? The answer to both questions is yes. Also, the accountId response should, if passed as a query to one of the account specific APIs, correctly and specifically identify the same account.
889 - Part 2 Our understanding is that if we set account type to CreditCard it would be mandatory for the response to include BankingCreditCardAccount. Refer to https://cdr-support.zendesk.com/hc/en-us/articles/900004410126-Optional-and-Conditional-field-clarifications. Is our understanding correct? In such case, would it be better to provide an empty string payment due date and payment amount fields set to 0? If you can please provide guidance on the appropriate value to avoid ADR validation errors. Setting the account type to credit card does not make the inclusion of the BankingCreditCardAccount mandatory. This structure is optional and should be supplied if it can be validly constructed.
895 we would like a ruling relating to including the x-fapi-interaction-id in 405 errors in response to ill-formed protected resource requests. As an example of protected resource request, let's use a banking customer API (e.g. Get Transaction Detail). If the request is incorrectly formed (e.g. POST /banking/accounts/{accountId}/transactions/{transactionId}) the correct response is a 405 error - Method Not Allowed. In the above example, must the 405 error include the x-fapi-interaction-id ? Please advise Reading through the FAPI spec we believe the x-fapi-interaction-id is required in 405 and 404 errors as they come from a protected resource (the server). Our vendor disagrees. https://openid.net/specs/openid-financial-api-part-1-1_0-final.html#protected-resources-provisions and point 7 mentioning errors points to https://datatracker.ietf.org/doc/html/rfc6750#section-3.1 but does not specify 404 and 405 behaviour. Your interpretation is correct, although this is not based on the normative standards. The CDR standards specifically call out the following for x-fapi-interaction-id. Note that this explicitly states that the interaction ID is mandatory for error responses for authenticated APIs.
896 Hi, can you please clarify why below obligation is set documented as a MUST for 1 Feb 2022 for (presumably) all DHs, when non-major ADIs do not have to enable secondary users until November 2022 ? Data Holders MUST implement the following data standards effective from 1 February 2022: Withdrawal: Secondary User Instruction There is a distinct difference between the obligation dates included in the phasing portion of the rules and binding dates in the standards. If a specific data holder does not have to implement a portion of scope, due to phasing or an exemption, then the standards for that scope do not apply. It is implicit in the standards where future dated obligations are expressed that they only apply to data holders that are required by designation and rules to implement the feature for which the obligation is applicable.
904 If a data holder has a major outage and needs to declare a disaster recovery situation and takes many hours to recover, what will the treatment be under the availability metrics. Is such an event a reasonable exemption to not meeting the availability non-functional, or would this type of event just be considered a breach for the period? Under the standards this would be a breach of the non-functional requirements. The standards only discuss the level of availability and make no comment on the cause of any unplanned outages. The regulatory response to such as situation is a determination for the ACCC enforcement team and I don't believe they have been giving definitive answers to questions such as these. The support portal is probably not the best avenue to get answers regarding likely enforcement. I would recommend reaching out to the ACCC directly.

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

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.