ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 13th of January 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT 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.15.0 Published Link to change log here
Maintenance 10th Maintenance Iteration To commence on 16th of February 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 13th of December 2021 View in browser here
DSB Newsletter 24th of December 2021 View in browser here
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 225 - Data Recipient Security Standards Link to consultation

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their stream of work

Organisation Stream Member
ACCC CDR Register Hopeson Chiao
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Eunice Ching
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

Ticket # Question Answer
841 I wanted to understand the rationale for the JWKS URI in the enrolment form and CDR register. The Well-known endpoint SHOULD provide the JWKS URI (based on the OIDC specs). Shouldn't the information here be used by the ADRs to access the Data Holder's JWKS instead of having that a separate entry? Guessing i am missing something here. Appreciate your inputs and the thought process here. As of V1.15.0 of the standards, we have provided further clarification. Please see the documentation updates from issue #189. The JWKS endpoint obtained during onboarding is published in the GetDataHolderBrands API. This is used for client authentication for DH to ADR communication. There is nothing preventing this endpoint from being the same as the one published in the OIDC Discovery document. The rationale for having aseparate endpoint configuration is that outbound calls to the Data Recipient may have access to different platform resources than the Identify Provider hosted by the Data Holder. This configuration provides the flexibility to keep these systems separate if required.
1268 Please could you validate my assumptions regarding documentation and endpoint versioning? 1. Documentation major version changes may cause a change in some, but not necessarily all, endpoint versions, e.g. a change in security profile would not change the version of unauthenticated endpoints 2. Documentation major version changes will impact the segment of all endpoint URIs, even if the change does not specifically relate to a particular class of endpoints, e.g. a change in security profile and unauthenticated endpoints 3. Multiple documentation major version endpoints (e.g. v1 and v2) will need to be available in production, even if the reason for the documentation version change does not specifically relate to a particular class of endpoints, e.g. a change in security profile would still require unauthenticated endpoints v1 and v2 to be available, until the v1 retirement date 4. Endpoint version changes generally occur due to response schema changes, e.g. BankingProductFeatureV2 and the new featureType enum values 5. Endpoint version changes would also occur due to query parameters changes. 6. An endpoint version is related to a documentation major version such that an endpoint version is supported by a data holder from its binding date and from the documentation major version in which it was first introduced. For example, endpoint x-v 2 introduced under CDS v2 would not be supported under CDS v1, and this is true irrespective of whether endpoint x-v 2 is backwards compatible with CDS v1, i.e. a change in security profile and unauthenticated endpoints In response to your questions/assumptions: Q: Documentation major version changes may cause a change in some, but not necessarily all, endpoint versions, e.g. a change in security profile would not change the version of unauthenticated endpoints A: We define a 'major' change as, by definition, changing all APIs as it would result in a regime wide change to the version in the base path. We don't anticipate changes like this occurring very often Q: Documentation major version changes will impact the segment of all endpoint URIs, even if the change does not specifically relate to a particular class of endpoints, e.g. a change in security profile and unauthenticated endpoints A: Yes Q: Multiple documentation major version endpoints (e.g. v1 and v2) will need to be available in production, even if the reason for the documentation version change does not specifically relate to a particular class of endpoints, e.g. a change in security profile would still require unauthenticated endpoints v1 and v2 to be available, until the v1 retirement date A: This is a fair assumption but we've never tested it because it hasn't happened yet. We wouldn't do this without Q: Endpoint version changes generally occur due to response schema changes, e.g. BankingProductFeatureV2 and the new featureType enum values A: Yes, although they can change due to underlying logic also. Basically, anything that would be breaking for the client with a heavy bias towards assuming a change is breaking Q: Endpoint version changes would also occur due to query parameters changes. A: If it was considered breaking. For instance, removing support for an existing query parameter maybe wouldn't require a version change. We specifically don't have a definition of 'breaking change' and consult case by case Q: An endpoint version is related to a documentation major version such that an endpoint version is supported by a data holder from its binding date and from the documentation major version in which it was first introduced. For example, endpoint x-v 2 introduced under CDS v2 would not be supported under CDS v1, and this is true irrespective of whether endpoint x-v 2 is backwards compatible with CDS v1, i.e. a change in security profile and unauthenticated endpoints A: Our intention is that when we introduce major version 2 we would go back to v1 for all endpoints because they would be on different paths entirely. There is likely to be a requirement to maintain v1 for a parallel period though.
1275 Would someone be able to help clarify something in the Joint Account wires under "Change to a less restrictive option" on this page https://www.notion.so/Joint-account-disclosure-option-management-service-365dcb00593b4cd89864da6d59732ff4 In the attached screenshot, when AH-B views the notification about a proposal made by another joint account holder. Is the representation here that the notification is opened/read inside the DOMS? I'm mainly trying to understand how annotation 1 (for rule 4A.6(1),(2)) is being addressed in the wires. According to rule 4A.6(1)(c) and (2), the data holder must provide a service to each joint account holder that allows the joint account holder to respond to a proposal by another joint account holder to change the disclosure option. Such a service is the disclosure option management service (DOMS). Citing this rule, I can confirm that these wireframes show AH-B providing a response to the proposal in the DOMS. Also thank you for bringing to my attention that the annotations are shifted (from your attached screenshot). I've fixed this issue as well.

Useful Links

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