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

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (6th of May 2021)

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: [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.9.0 Published Link to change log here
Standards Version 1.10.0 Drafted Link to Version Project Board here
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 7 Link to consultation
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to ACCC Newsletter Link here
TSY Newsletter 30th of April 2021 Edition View in browser here
DSB Newsletter 30th 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 166 - CX metrics for Data Holders Link to consultation
Consultation Decision Proposal 180 - Energy Draft Feedback Cycle 3 Link to consultation
Workshop 11th of May 2021: DSB - Energy - Draft Standards API Feedback Link to register
Design Paper Design Paper: an ‘opt-out’ data sharing model for joint accounts in the banking and energy sectors Link to consultation
Design Paper Design Paper: a peer-to-peer data access model in the energy sector Link to consultation
Action CTS Questions from last week's call Answered below: Question1: The CTS requires Payees endpoint to work to pass it's tests. This is a phase 2 endpoint, are Phase 2 endpoints in scope for July? Answer1: This is a bug, we are working to make phase 2 endpoint testing optional Question2: The CTS requires all scopes from the SSA to be accepted including Phase 2 scopes. Is this intentional? Answer2: This is related to the above and we are working to make phase 2 scopes optional in the tests. Question3: Are we able to get a copy of the payloads the CTS sends for each test scenario? Answer3: Please refer to the technical guidance material. Payloads are customised for each participant and are in accordance in CDS. Please refer to the non-normative examples for reference. Question4: Does CTS test DCR with both July and November scopes? Answer4: Yes it does, however as explained above we will be making November scopes optional.
CTS CDR Support Portal article: Conformance Test Suite: version history and scenarios Link to article here
ACCC Publication on "Compliance guidance for data holders in the banking sector" Link to Guidance

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 Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

Introduction of the Design Paper consultations by James Bligh and Michael Palmyre.

Announcement by Treasury Consultation location GitHub: Design Paper: an ‘opt-out’ data sharing model for joint accounts in the banking and energy sectors GitHub: Design Paper: a peer-to-peer data access model in the energy sector

Today's discussion seeks to cover:

  • What is a Design Paper? How does it differ vs the current consultation process?
  • How to approach reading the Design Paper in it's entirety.
  • How and where can I submit feedback to this process?
  • Where are the papers located?

What we won't cover this week:

  • Policy and Rules related topics and questions

What is the plan for supporting Community Feedback on the Design Papers: Today (6th of May 2021): Overview of Design Papers, purpose, how to read, where to send feedback

  • CDR Implementation Call to continue in normal format

11th of May 2021: Workshop: "DSB | Energy | Draft Standards API Feedback"

  • Update on the current Energy Standards
  • Include an update segment on the "a peer-to-peer data access model in the energy sector" (working on structure)

13th of May 2021: an ‘opt-out’ data sharing model for joint accounts in the banking and energy sectors

  • The CDR Implementation Call will be extended to 5pm AEST
  • A workshop style format will be adopted (agenda to be announced)
  • Normal agenda to be dropped in favour of focusing on the Design Paper

20th of May 2021: facility for a follow-up session on either Design Paper, adopting a similar format as the 13th of May:

  • If required the CDR Implementation Call will be extended to 5pm AEST
  • If required a workshop style format will be adopted (agenda to be announced)
  • If required a focus on questions or feedback
  • If required the normal agenda to be dropped in favour of focusing on the Design Paper

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
431 We are planning to go in with get metrics V2 only (ie we are not planning to build a v1 version). Can we please get confirmation that we can go in with only that version prior to 31st July? Non-major ADIs should be implementing V2 of the Get Metrics API. Please see the Get Metrics FAQs we published earlier this year for further information about implementing the Get Metrics API.
639 The discussions around how to handle Authorisations for Joint Accounts raised some queries from our development team, Please consider the following scenario: - We have an Authorisation associated with 2 accounts - Both accounts are single owner accounts and thus the authorisation is 'active' (...lack of better word) for each account The ADR requests a disclosure using this Authorisation. Our system checks the authorisation and recognises that both accounts are eligible and begins retrieving the accounts information. One of the accounts (say Account A), is successfully processed and a fully compliant JSON response fragment is generated, however the second Account (say Account B) encounters some error during processing. As a result we cannot create a fully compliant JSON fragment for Account B. Our current implementation will recognise that it is unable to fully respond to the disclosure request and will return a JSON error object to the calling ADR - even though it could have sent details about Account A (which it successfully processed). Our response to the ADR will be an error response saying something went wrong. Now lets consider the situation where Account A remains as is, but suppose Account B was a joint account. The Authorisation is created and Account A is 'active' in the Authorisation, however Account B is currently 'Pending' as it's second owner has yet to approve the Authorisation. In this scenario, if the ADR requests a disclosure using the Authorisation we will only return Account A (as Account B is still pending the second owners approval of the Authorisation - lets also assume Account B would have been successfully processed if it's joint account owner had approved it). Our issue is that we are now in a position where have two types of "reasons" as to why an Account is not returned in a disclosure. One reason is that there is some corruption in the account which causes a technical issue. This reason causes the entire response to register as a failure. This is an 'all or nothing' approach. We won't return other accounts which were successfully processed as an error occurred somewhere and we don't want to send partial information to the ADR. The second "reason", is more due to business rules. In our second example Account B is not yet eligible as it's authorisation is still Pending. In that case we follow a 'best efforts' approach and return just Account A and omit Account B from the response. Is the above interpretation correct? Should we distinguish between these two different 'types' of errors and handle them as such? Best Effort vs All or Nothing! A slightly related question is one where we are unable to successful create a compliant JSON response for an Account. Suppose there are mandatory fields which are missing. Our current approach is the 'all or nothing' approach and we will return an error response. However, we are now thinking that a 'best efforts' approach could be considered in this scenario as well. Meaning, even if we had missing mandatory data, we could still send a JSON response. We don't think this is a good solution, but would like to understand what is the general approach taken and what is required. Currently the standards require you to respond with an error and do not allow partial responses. That said, if you see value in partial responses I'd encourage you to raise it as a change request so we can consult on with the rest of the community. It was feedback we received during consultation on the Enhanced Error Handling (see https://github.com/ConsumerDataStandardsAustralia/standards/issues/155#issuecomment-818409831) so there are others thinking along similar lines. In our response to the feedback I did state that it would require a community change request to progress. For the second part of your question, you indicate different issues resulting in different errors occurring. In these situations, which error to respond to is up to the DH based on their solution: noting that different implementations may encounter those errors at different points in their implementation stack / application code. In the two scenarios you highlight, I would expect most implementations would experience the joint account election error first and respond accordingly without further processing the request and encountering the non-compliant JSON response error.
641 Please can you advise whether the complete and final CX Guidelines have been published for the July release or whether some items are still outstanding and yet to be published? All of the DH-related CX Guidelines for the July release have been published online here. We will be updating and releasing the remaining ADR-related artefacts in May/June for July obligations that relate to ADRs.
770 Is Data Holder expected to maintain the same/existing "cdr_arrangement_id" received from ADR after it has successfully "amended the consent" (by revoking old consent and creating new one to represent the amendment)? if the ADR is presenting a valid cdr_arrangement_id indicating the consumer's desire to continue the existing arrangement with changes the DH needs to maintain this ID. The purpose of this ID is to provide a continuous identifier to link the extensions to a consumer's consent under their original arrangement.
772 As per the specification[1], it says "The request MUST include the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body: The request MUST include the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body: " However, the sample request shown in the specification is as follows. Request POST https://data.holder.com.au/arrangements/revoke HTTP/1.1 Host: data.holder.com.au Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...& cdr_arrangement_id=5a1bf696-ee03-408b-b315-97955415d1f0 So, do we only need to send the cdr_arrragement_id or all the above parameters in the request? If we are sending only the cdr_arragement_id in the request, how does the client authentication is handled? Is the CDR arrangement revocation endpoint similar to the /token endpoint? Also, could you please send us a sample request & response so we can get a better understanding? Kindly appreciate your feedback and guidance on the above as soon as possible. [1] https://consumerdatastandardsaustralia.github.io/standards/#end-points [Question] So, do we only need to send the cdr_arrragement_id or all the above parameters in the request? [Answer] Hi Chandima, the ADR or DH must send the cdr_arrangement_id as well as any parameters required for client authentication of the DH at the ADR or client authentication of the ADR at the DH. The statement you refer to requires the cdr_arrangement_id but doesn't preclude the other parameters. They are required as per the Client Authentication section of the standards: https://consumerdatastandardsaustralia.github.io/standards/index.html#client-authentication [Question] If we are sending only the cdr_arragement_id in the request, how does the client authentication is handled? [Answer] You must send the necessary client assertion for authentication as well as the cdr_arragenement_id. [Question] Is the CDR arrangement revocation endpoint similar to the /token endpoint? [Answer] Yes. [Question] Also, could you please send us a sample request & response so we can get a better understanding? [Answer] The DSB does not provide a sample outside of what is provided in the non-normative examples. [Question] For which go-live deadline will the above changes be affected? [Answer] The CDR Arrangement Revocation endpoint was required since November 2020. For non-major DHs going live on July 2021, it will be required at commencement of data sharing on that date. [Question] Will the CDR arrangement revocation endpoint be tested in the CTS? [Answer] Yes. The CTS tests both the ADR and DH hosted CDR Arrangement Revocation endpoint. [Question] If so, what version of the CDR arrangement revocation endpoint will be tested? [Answer] There is only one version of this defined in the standards. The current version will be tested.
775 We want to clarify if an error payload is expected for error scenarios that return an HTTP Status code 401 Based on https://consumerdatastandardsaustralia.github.io/standards/#http-response-codes and the November 2022 Obligation date to support standardised error codes, 1. For July 21 (Current standards) a. Is an error payload expected and/or allowed with the HTTP 401 response? b. If an error payload may be provided, it must conform to the the error schema (code, title and description), is it valid to provide an empty string for any of these mandatory fields in the error payload (title and error)? 2. For Nov 2022 Obligation dates a. Is an error payload expected and/or allowed with the HTTP 401 response? b.If an error payload may be supplied, are we to use a standardised error code , description and title for 401 errors Scenario: Authorization header missing or invalid token)? Reference: https://github.com/ConsumerDataStandardsAustralia/standards/issues/154 https://github.com/ConsumerDataStandardsAustralia/standards/issues/155 If the 401 Unauthorized response is covered by an upstream normative standard (e.g. oAuth token endpoint call) then CDS is silent - the DHs should respond according to the normative standard. If the 401 Unauthorized response is covered by a section of the CDS outside of normative standards implementation, then it should use the standard error response code and title and the ResponseErrorList structure where specified. Currently the CDS does not specify any 401 errors that must be responded to by the CDR API endpoints. Only 422 error responses are explicitly articulated in the current version of the CDS against some endpoints. Bearing in mind that the new changes from Enhanced Error Handling do touch upon 401 scenarios however there are no standard CDR error codes proposed to respond with 401. This is because those errors were suitably covered by the upstream normative standards.

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