ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 2nd of June 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

CDR Implementation Call Banner

Agenda & Meeting Notes

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.170 Published Link to change log here
Maintenance DSB Maintenance Iteration 11: Agenda & Meeting Notes on 25th of May 2022 Link to the agenda and minutes
Maintenance Meet next week on the 8th of June 2022 To receive an invitation: reach out to [email protected]
Maintenance Additional session on the Tuesday 14th of June 2022 Focused on Energy items for Maintenance Iteration 11
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 6th of April 2022 View in browser here
DSB Newsletter 27th of May 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
Action Question taken on notice: in regards to SSO with the Consumer Data Standards CDR Support Portal - SSO and CDR authentication

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 Emma Harvey
ACCC CTS Preeti Patel
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy & MI11 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.

Answer provided

Ticket # Question Answer
1427 We are considering the scenario where a Data Holder may have a consumer that has an "open gas account" or “open telco account” but a "closed electricity account”. When there are multiple open accounts with a Data Holder and a customer closes one account the authorisation does not necessarily immediately expire [as it would e.g., by operation of Rule 4.26(1)(c)]. This depends on whether the consumer remains an eligible consumer [as defined in Schedule 4, clause 2.1]. Our interpretation is that given Consumer Data Right (Energy Sector) Designation 2020 and interactions with the CDR Rules is that “open gas accounts” or an “open telecommunications account” would not be considered an “open account” for purposes of determining whether a customer remains eligible for CDR. [As the Energy Sector Designation covers gas and electricity, however gas does not fit the definition of an eligible customer under the CDR Rules. N.B. the telecommunications sector is yet to be designated.] However, we are unsure if Schedule 4, part 3, clause 3.2(2)(b)(iii)(A) may influence whether a customer remains eligible particularly if a ‘relevant account’ could have cross-sectoral implications – such as a gas or telco account. Could you please give us direction on the policy intent regarding interpretation of Schedule 4, part 3, clause 3.2(2)(b)(iii)(A). Also Note 2 to clause 3.2(2) [see Note 1 below] suggests that closed accounts are in scope, but references that the consumer must be eligible (which we understood to be the case only the case if the account is open) – are you able to clarify the intent of this Note please? For a consumer to be eligible in relation to a retailer, the consumer must be a customer of the retailer in relation to an eligible arrangement as stated in clause 2.1(1)(a) of Schedule 4. Clause 1.2 of Schedule 4 to the rules and Section 5(1)(b) of the Energy Sector Designation define a ‘customer’ as a person who purchases electricity or to whom electricity is supplied by a retailer. Clause 1.2 and 2.1(2) of Schedule 4 define an eligible arrangement as “an arrangement that relates to one or more connection points or child connection points for which there is a financially responsible market participant in the National Electricity Market.” Clause 3.2 of Schedule 4 deals with consumer data that is required or voluntary and does not relate to a CDR consumer’s eligibility. A CDR consumer can share data on closed accounts if they remain eligible CDR consumers with the relevant data holder despite the account closure. If the person continues being eligible in relation to the data holder (for example, they have another account with the energy retailer which is open and satisfies the eligibility criteria), the person will continue to be able to share CDR data from the closed account subject to clauses 3.2(4) and (5) of schedule 4.
1475 Can you please confirm our understanding that required data for closed accounts is 24 months before the day of the request? We note references within the CDR - i.e. Schedule 4, 3.2(2)(iii)(B) which defines required billing data for a time that is not more than 2 years before the day of the request. However this is not defined specifically in relation to required data for closed accounts - see Schedule 4, 3.2(7) Thank you for your question. Schedule 4, clause 3.2(7)(c) of the CDR rules specifies that for a closed account, any CDR data not excluded by 3.2(7)(a) or (b) that “relates to a transaction or event that occurred more than 2 years before” is not required consumer data. This means that billing data held by a retailer (and metering data held by AEMO) that relates to an event or transaction that occurred less than 24 months before the date of a consumer data request is required consumer data for closed accounts. However, note that the CDR Rules only require a retailer data holder to share CDR data that relates to a closed account if the CDR consumer remains an eligible CDR consumer in relation to the data holder (see Rule 1.10B and Schedule 4, clause 2.1 for the definition of an eligible CDR consumer in the energy sector).
1513 User Info API for Nominated Representatives In regards to the User Info API in the OAuth Specifications (that provides information about the user establishing the consent), this oAUth API mostly deals mostly with the consumer use case. For the obligations related to business consumers, for a business account user consenting to share business account information that they are a nominated representative for, should User Info represent the business account info or the nominated representative? The UserInfo response relates to the authenticated end user. For individual consumers this is currently the consumer. For non-individual consumers this will be the data of the nominated representative.
1522 Scheduled Payments and Direct Debits requests where there is no data Where a request is made to either get scheduled payments or direct debits on one or multiple accounts and there are no scheduled payments or direct debits on the account. What should the response be. i.e. Status Ok with an empty array or an error code as the mandatory fields can't be populated. If the request is valid you must respond with a 200 OK and an empty array.
1544 Error Code 404 - Difference between Invalid and Unavailable data The 404 error description highlights that the "Unavailable" and "Invalid" are differentiated based on whether the ID provided in URL is permanently unavailable for "Invalid" and available but not shared due to status for "Unavailable". In CDR rule 3.5(1)aa and 4.7(1)(c)- The status mentioned are "blocked" and "suspended". Should Energy Retailer send 404 - "Unavailable" for data which is blocked and suspended. Similarly send "Invalid" if the data is not able with Energy retailer? The guiding principle for Unavailable vs Invalid is whether future calls to the same resource are likely to be responded to. If the account is temporarily unavailable (for example a transient hold on the account) then Unavailable is the appropriate response. If however, for protection of the vulnerable consumer or the account is no longer associated with the consent, then Invalid is the appropriate response. Business rules within each Data Holder will also play a role in determining how you handle each scenario. This is left to the discretion of the Data Holder.
1549 As part of the OIDC Authorization Code Flow, Data Holders are expected to support JARM. Questions: 1. For the "authorization_signed_response_alg attribute" should the DH use PS256 or leave it to default which is RS256? 2. Should the JWT be encrypted? 3. If yes, what should be the OB recommended values list for these attributes. a. authorization_encrypted_response_alg b. authorization_encrypted_response_enc Question 1: For the "authorization_signed_response_alg attribute" should the DH use PS256 or leave it to default which is RS256? Answer: RS256 is explicitly excluded by FAPI. FAPI provides requirements for allowed signing algorithms in section 8.6: https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations Question 2. Should the JWT be encrypted? Answer: No. There is currently some discussion in the Maintenance Iteration 11 to exclude encryption of responses (this would be a constraint to the JARM spec) Question 3. If yes, what should be the OB recommended values list for these attributes. a. authorization_encrypted_response_alg b. authorization_encrypted_response_enc Answer: Currently, the algorithms specified in JWE apply. The JARM spec states these requirements. https://openid.net/specs/openid-financial-api-jarm.html in section 6: https://openid.net/specs/openid-financial-api-jarm.html#authorization-server-metadata - authorization_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response. - authorization_encryption_enc_values_supported OPTIONAL. JSON array containing a list of the JWE [RFC7516] encryption algorithms (enc values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.
1557 We have a question for the FAPI 1.0 upgrade (i.e. https://github.com/ConsumerDataStandardsAustralia/standards/issues/209) For September 16th obligation date, under the heading of "Authorization Code Flow" it states "Data Holders MAY support the Authorization Code Flow in accordance with FAPI 1.0 Advanced. This requires JARM and PKCE." The above statement states "MAY" however in the 'Future Dated Obligation' page for September 16th 2022, it states "Data Holders and Data Recipients MUST support FAPI 1.0 Final including [RFC9126], [RFC7636] and [JARM]". The 2 sites contradicts each other as one says "MAY" and the other says "MUST". Can you please let us know if it's indeed a "MAY" or "MUST" so we can prioritise our upgrade ? the intention of the statements in the future dated obligations is to indicate any Data Holder adopting Authorization Code Flow in Phase 2 must do so according to FAPI 1.0 Final including [RFC9126], [RFC7636] and [JARM]. The requirement for Authorization Code Flow support in Phase 2 is actually a SHOULD, not a MAY, but this does give discretion to the Data Holder. Whilst we encourage Data Holders to implement and support the Authorization Code Flow from September, it is only mandated from April 2023 (after which time the OIDC Hybrid Flow is deprecated). Please note that "MAY" support for Authorization Code Flow is July 2022, "SHOULD" support is September 2022 and "MUST" support is April 2023.

Useful Links

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