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

CDR Implementation Call Banner

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.16.0 Published Link to change log here
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 2nd of March 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 4th of March 2022 View in browser here
DSB Newsletter 4th of March 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date Link to consultation
Knowledge New Video: Summary of the legislative framework and CDR Rules - with Wendy Hau (10/03/2022) Link
CX Guidelines Update on the 8th of March 2022 Link to Change Log
Design Paper Design Paper: Consumer Data Right Rules and Standards for the Telecommunications Sector Link to DSB GitHub Link to Treasury page

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
DSB CX Standards Michael Palmyre
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: #747194

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
Taken on notice 03/03/2022 Why aren't usage metrics (customer count) published along with the performance metrics on CDR website? Will the ACCC publish this? Data sharing in the Consumer Data Right occurs directly between data holders and data recipients, and does not pass through the ACCC. We are working with data holders to get accurate and timely information about ecosystem performance and the number of data sharing consents granted by customers. That work is continuing, and we intend to release information relating to this later this year.
1311 Is there a preference as the Guidelines refer to Consumer Dashboard. Yet the sample wireframes available on the link from the data standards refer to Data Sharing / Data Sharing Arrangements and Consumer Dashboard : https://d61cds.notion.site/Dashboards-e7c2aadc4677412b84f282272db9719e ? lthough the Rules use the term ‘consumer dashboard’, there is no requirement for participants to use that specific term. The name used for the dashboard is at the discretion of the data holder. However, data holders should consider whether their naming conventions are conducive to the objects referred to in section 56AA of the Competition and Consumer Act 2010.
1313 Part1 The future dated obligations in the standards state in FAPI 1.0 Phase 2: "Data Holders and Data Recipients MUST support FAPI 1.0 Final including RFC9126 , RFC7636 and JARM". Our understanding is that PCKE and JARM are only applicable for OIDC authorisation code flow to address the control gap by introducing auth response signature for integrity and code verifier challenge to authorisation request to prevent manipulation of code in transit. The OIDC authorisation code flow is mandatory obligation from FAPI 1.0 Phase 3. Can you please verify that it is not a mandatory requirement for DH to support PKCE and JARM in Phase 2 should our understanding be correct? The intention of that statement was to refer to the FAPI 1.0 Final standard's reliance on the RFCs listed. The notable requirement is that DHs and ADRs must implement against the PAR RFC 9126. This does require that PKCE RFC 7636 is supported. This is a mandatory requirement in the FAPI 1.0 Final spec section 5.2.2: 1. shall require PAR requests, if supported, to use PKCE (RFC7636) with S256 as the code challenge method. JARM would be required when moving to the Authorization Code Flow. If you feel any of the statements in the transition require cleaning up a change request might be beneficial.
1313 Part2 We have completed a review of the upstream standards and can't find any reference of the PCKE in the context of the hybrid flow. From our analysis of the standards, PKCE and JARM are applicable to the authorisation code flow. Similarly our vendor doesn't support PKCE for hybrid flow. Our intention is to support PCKE and JARM only when moving to the authorisation code flow as part of phase 3. Appreciate your view on whether we have understood that standards correctly from data holder perspective. the context for PKCE is in the request sent to the PAR endpoint. So this is pre-hybrid flow. You are correct that PKCE is also required for the authorisation code flow. https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server
1313 Part3 We have reviewed the FAPI standards and understand that it is mandatory requirement. Our confusion is that the adoption of FAPI 1.0 is spilt across three phases. Within the Authentication Flow section of the standards (https://consumerdatastandardsaustralia.github.io/standards/#authentication-flows) it states: From September 16th 2022 (FAPI 1.0 Migration Phase 2), the following requirements apply in addition to the FAPI 1.0 Migration Phase 1 requirements: Data Holders MUST support the OIDC Hybrid Flow. Data Holders MUST support FAPI 1.0 Advanced Profile ([FAPI-1.0-Advanced]). Data Holders MAY support [PKCE] (RFC7636). Data Holders SHOULD support OIDC Authorization Code Flow. However in the future dated obligations the data holder and data recipient obligations are combined and it states for Phase 2: Data Holders and Data Recipients MUST support FAPI 1.0 Final including RFC9126 , RFC7636 and JARM In summary, the statements are conflicting as to whether we MAY or MUST support PKCE in Phase 2 as the data holder. We understand that we MUST support PKCE in Phase 3. Can you please clarify whether we MAY support PCKE in phase 2 as per authentication section. thanks that's a good pick up. This looks to be a documentation defect in the Phase 2 statements because PKCE is required in accordance with PAR as part of FAPI 1.0 Advanced section 5.2.2. (18). I will raise a change request on Standards Maintenance.
1333 This article goes some of the way to answer the following question, but we would appreciate a clear position, or a wording update to Rules to refer to "if an account (be it online, client, or a specific bank account) is blocked or suspended" which would clarify: https://cdr-support.zendesk.com/hc/en-us/articles/360004504675?input_string=appropriate+treatment+of+account+blocks+that+can+be+temporary%2C+and+subsequently+lifted We have a question regarding treatment of temporarily ‘blocked accounts’ (in the sense of ‘online banking accounts’, or more generally ‘client accounts’, rather than specific ‘bank accounts’). Scenario: Assume a consumer meets the Banking Sector ‘eligibility’ rules: * Part 1 Div 1 > 1.10B> “…18 years of age or older…” and “…is an account holder for an account with the data holder that is open…”; and * Schedule 3 > Part 2> 2.1 “…in relation to a particular data holder in the banking sector at a particular time, is that the person is able to access the account online…” Next, a block (which can subsequently be lifted) is added to the consumer’s online banking account, or to the client record. There are many situations where a temporary block can be applied. Moreover, a block can be of two types [1] a block that only prevents the customer from conducting transactions on the account but does not block the ability of the client to login and view their accounts; OR [2] a block that does not allow the customer to login to his online banking account - primary digital channel - or conduct any transactions. Examples: * ‘Judicial instruction’ (say, the consumer is in arrears on alimony payments); - this is an example of type [1] block described above * The consumer notices unusual activity and asks the bank to temporarily suspend online access - this is an example of type [2] block described above The question: what is the expected treatment by the Data Holder? Does the Data Holder have discretion to apply either of: (a) The ‘Authorisation expiry’ rules? (because the consumer is no longer considered eligible); or (b) The ‘Refusal’ rules? (because there is legitimate basis to refuse ADR data sharing requests while the block is in place) ...or will the treatment vary, depending on block type [1] or block type [2] This is an important distinction due to the respective treatment required under each. In the case of: * Treat as 'Consumer is now ineligible': all active authorisations are to be expired by the data holder; if-and-when the block is lifted the Consumer will need to re-consent / re-authorise entirely new consents; or * Treat as a 'Refusal' (say under risk of harm or abuse, or that the ‘online account’ is blocked or suspended) – the data holder will refuse ADR data sharing requests during the ‘blocked period’, and report these refusals to the regulator under the specific refusal rule invoked. Relevant Rule references for ‘withdrawal of consent’ and ‘refusals’ are below for ease of reference. (R1) Withdrawal of consent due to ineligibility: - Division 4.3 > Subdivision 4.3.2B (Withdrawing consents) > 4.26 Duration of authorisation to disclose CDR data> (1)(c) “…(c) if the CDR consumer ceases to be eligible in relation to the data holder;” (R2) Data Sharing Refusal: - Division 4.2 (Consumer data requests made by accredited persons to CDR participants)> Subdivision 4.2.3 (Consumer data requests by accredited persons to data holders)> 4.7 (Refusal to disclose required consumer data in response to consumer data request), under - (1)(a) “…if the data holder considers this to be necessary to prevent physical, psychological or financial harm or abuse”, or - (1) (c) “...in relation to an account that is blocked or suspended” Thank you for your enquiry. We have recently updated our knowledge article on ‘Blocked or suspended accounts'. This knowledge article provides information relevant to your enquiry.
1355 Part1 It doesn't seem to be explicitly stated but can you please clarify that the DCR Endpoints for Update and Delete are essentially appended to the base url advertised as registration_endpoint? Ie. If registration_endpoint is domain.com/long/dcr/url does that mean the following? DCR Registration Endpoint: domain.com/long/dcr/url DCR Get/Update/Delete: domain.com/long/dcr/url/{clientId} The registration_endpoint value specified in the OpenID Provider Configuration End Point section of the standards is not a base url, but instead the full endpoint. Therefore, in the DCR APIs section of the documentation, we have used the path /register as a proxy for this url. Looking at the non-normative examples, I do see where the confusion may lie. The duplication of the /register in the path is not intended. There is an opportunity here to clear this up. GET https://data.holder.com.au/register/register/{ClientId} HTTP/1.1 Please let me know if you require any further information.
1355 Part2 I guess by way of example, if a Holder is advertising the registration_endpoint as: https://mtls-api.holder.com/v1/oauth2/applications What is the URL for expected for GET/PUT/DELETE {clientId}? The paths used to call the DCR API endpoints are retrieved from the OIDC Participant Discovery Endpoint registration_endpoint value. Using your example, the registration endpoint is https://mtls-api.holder.com/v1/oauth2/applications The DCR API endpoints would be called as follows: POST: https://mtls-api.holder.com/v1/oauth2/applications GET: https://mtls-api.holder.com/v1/oauth2/applications/{clientId} PUT: https://mtls-api.holder.com/v1/oauth2/applications/{clientId} DELETE: https://mtls-api.holder.com/v1/oauth2/applications/{clientId} In order to improve the documentation, I have raised the following change request on the standards maintenance repo: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/487
1360 I am seeking clarification if non-authenticated CDR endpoints require PFS and are restricted to the 4 ciphers mentioned in section 8.5 of [FAPI-RW-Draft]? Example: GET /banking/products The risk of an adversary compromising the request offers no gain since the data is public anyway. the FAPI profile applies to authenticated resource endpoints only.
1368 Just flagging an errata in the rules. Rule 4.6A, Note 2 makes reference to clause 4.13 of Schedule 3 which no longer exists. Thank you for flagging an errata in the CDR rules. We have passed this on to Treasury as they are responsible for developing and amending the rules.
1378 Reference to https://consumerdatastandardsaustralia.github.io/standards/#future-dated-obligations & https://consumerdatastandardsaustralia.github.io/standards/#client-authentication For July 2022 there are changes to "Self-Signed JWT Client Authentication" which relate to changes to the client authentication and validation of the aud claim that allows a Dataholder to authenticate to a DataRecipient end point Just wanted to confirm that there are no changes to the Self-Signed JWT Client Authentication mechanism when the Register calls the DataHolder end point (getMetrics) and the changes are limited to DH->DR? that's correct. It only affects the DR hosted endpoint.

Useful Links

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