Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 5th of May 2022

Jump to bottom
CDR API Stream edited this page May 5, 2022 · 2 revisions

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.16.1 Published Link to change log here
Standards Next Update will be Version 1.17.0 Will incorporate changes completed from the 10th Maintenance Iteration
Decision Proposal 237 will contain the decision taken to to the Data Standards Chair
Maintenance DSB Maintenance Iteration 11: Agenda & Meeting Notes on 27th of April 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 6th of April 2022 View in browser here
DSB Newsletter 14th of April 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
Consultation Decision Proposal 240 - ADR Metrics Feedback closes 27th of May 2022
Link to consultation
Consultation Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation Feedback closes 27th of May 2022
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 Peter McCool
ACCC CTS Preeti
DSB CX Standards Michael Palmyre
DSB Technical Standards - Energy & MI11 Hemang Rathod
DSB Technical Standards - Register Ivan Hosgood

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
1307 Given the recent security profile changes in in transition to FAPI Final, we would like to clarify our obligations (i.e. MUST) as a Data Holder.
From September 16th 2022 (FAPI 1.0 Migration Phase 2)
1. We are required to continue supporting the current OIDC Hybrid Flow without the use of PAR?
2. We are required to support OIDC Hybrid Flow with PAR as per FAPI-1.0-Advanced without the use of PKCE?
3. Furthermore we are required to support PAR in conjunction with PKCE?
From April 7th 2023 (FAPI 1.0 Migration Phase 3)
1. We are no longer required to support the OIDC Hybrid Flow, and can reject such authorisation requests?
2. We are required to support the Authorization Code Flow?
3. Authorisation Code Flow must only be supported in combination with PAR, PKCE, and JARM?
4. response_types of ‘code’ must only be supported, and ‘code id_token’ deprecated?		 From September 16th 2022 (FAPI 1.0 Migration Phase 2)
[Question] 1. We are required to continue supporting the current OIDC Hybrid Flow without the use of PAR?
[Answer] Data Holders must already support PAR. From September 16th 2022, Data Holders must support the latest version of PAR being RFC9126.
[Question] 2. We are required to support OIDC Hybrid Flow with PAR as per FAPI-1.0-Advanced without the use of PKCE?
[Answer] From September 16th 2022, Data Holders must support RFC9126 and PKCE. This is independent of the authorisation flow used. PKCE in use with PAR is a requirement in FAPI 1.0 Final
[Question] 3. Furthermore we are required to support PAR in conjunction with PKCE?
[Answer] Correct, RFC9126 must be used in conjunction with PKCE.
From April 7th 2023 (FAPI 1.0 Migration Phase 3)
[Question] 1. We are no longer required to support the OIDC Hybrid Flow, and can reject such authorisation requests?
[Answer] This is allowed. You may continue to support the hybrid flow after
2. We are required to support the Authorization Code Flow?
3. Authorisation Code Flow must only be supported in combination with PAR, PKCE, and JARM?
4. response_types of ‘code’ must only be supported, and ‘code id_token’ deprecated?
1313 Thanks Mark for the confirmation. We have few question/clarification needed to implement PKCE with PAR.
1. In the PKCE flow we will not have request object instead we will have code_challenge and code_challenge_method. In this case whatever the custom claims we get from request object how to expect these in /PAR with PKCE flow?
a. How the cdr_arrangement_id will be passed ?
b. How we will get sharing_duration ?
Assumption – As of now we are assuming these prams will come as additional query parameter.
2. In request object we also have id_token and userinfo claim, I think in this case we will return the default idtoken (if response_type is code, id_token) and userinfo?
Assumption – As of now we are assuming these will be default values return e.g userinfo we will have only sub as no claims are passed. For id_token we will not have any custom claims.		 As part of change request #458 this will cover the non-normative examples for the use of Hybrid and Authorisation Code flows in combination with PKCE and JARM. There will be a sequence diagram that covers the end-to-end flow as well.
PKCE claims are to be presented within the request object and the Data Holder must ignore the PKCE claims if they do not support the full PKCE flow.
1388 With regard to the expected response for GET calls, we would like to confirm the expected behaviour in the case of a bulk GET request (where no account numbers are provided).
In the case of a bulk GET (accounts) request, we will:
A) If some accounts are shareable, return a 200 with a list of accounts that are shareable; OR
B) if no accounts are shareable, return a 403 with no account numbers listed in the response
If some accounts are shareable – 200 response
This behaviour appears to align with the zendesk guidance that states ‘In a call to the Get Accounts API, the DH should return only the list of accounts that can be shared. If an account is not shareable it must not be returned in the accounts list.’: Accounts that cannot be shared – Consumer Data Standards Australia (zendesk.com)
Blocked accounts on the consent or accounts that are unable to be shared for any other reason will not be returned, and no details of these accounts or why they are not able to be shared will be provided as there is no means to provide this information.
We note that returning a 200 means that if an account is not being shared under Rule 4.7 (refusal to disclose), then the ADR will not be informed of the refusal. However, our view is that if an error were to be returned, particularly on the initial call made by the ADR, this would have the potential of stopping data from being able to be shared as the ADR may not receive the list of valid account IDPermanence IDs.
If no accounts are shareable – 403 response
Given no accounts can be shared, our view is that a 403 response is appropriate because the ADR is informed that they will not receive any account data, and will be informed if we have refused to disclose.
Please confirm if our understanding is correct.
We would be referring to any of the bulk GET requests, where the request is made without providing the account numbers in the request.
• Get Accounts – GET /banking/accounts
• Get Bulk Balances – GET /banking/accounts/balances
• Get Bulk Direct Debits – GET /banking/accounts/direct-debits
• Get Scheduled Payments Bulk – GET /banking/payments/scheduled		 In the case of a bulk GET (accounts) request, we will:
A) If some accounts are shareable, return a 200 with a list of accounts that are shareable; OR
[DSB Answer] That would be correct. For bulk APIs a 200 OK response with the resources that are shareable is correct
B) if no accounts are shareable, return a 403 with no account numbers listed in the response
[DSB Answer] For bulk APIs we have previously indicated that a 200 OK response with no records is the desired implementation. 403 Forbidden was reserved for security issues such as "Token has incorrect scope or a security policy was violated". This would indicate that the resource server understood the request but refused to authorise the request. In you scenario where there are no valid accounts then the resource server is not refusing the request but has no valid resources to return in the response list.
1447 Clarification to requirement “Data Holders that do not support [PKCE] MUST ignore PKCE claims and MUST NOT reject clients sending PKCE claims”
This is a clarification to the Data Standards: Authentication Flows - for Data Holders for FAPI 1.0 Migration Phase 1 from 4 July 2022 (Link here).
By complying with the requirement above, the DH may respond in a manner that is unexpected by the ADR, which generates a sub-optimal result for the ecosystem. Can you please confirm if this is the intention (during the transition) or an improvement should be considered? The details of this is provided in the attached.		 the scenario 2 was what was considered with that statement in the standards. If the client is initiating Authorization Code Flow then the DH must support PKCE and the ADR shouldn't be initiating an Authorization Code Flow request if the DH doesn't support is as a response_type with PKCE and JARM.
The intention was that if the ADR was sending PKCE claims in the Hybrid Flow they should be ignored so it doesn't cause any issued to clients operating across many DH implementations. You are absolutely correct that the ADR shouldn't be sending those claims to the DH because they should check the DH's OIDD before constructing their authorisation request.
If you believe that it is better to reject clients sending these claims in the Hybrid Flow I'd recommend raising a change request on Standards Maintenance. oting this has now been raised as a Standards Maintenance change request. We will discuss this in Maintenance Iteration 11.
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/500
1461 Would you be able to assist in clarifying what we need to expose for the 'lendingRates list" for the Get Account Details end point? for applicable accounts this would be the lending rates specific to the negotiated account.
The Lending Rate structure and its contents are described here: BankingProductLendingRateV2.
1477 Under issue 401, decision is to adopt additional feature types for v4 Get Product Detail.
During the overlap period between V3 & V4 of Get Product Details, it may happen that one of the new product features is being used for the V4 but not available for V3. What do we do while responding in such scenarios?		 your v3 response would omit the new product features or represent them under another applicable product feature type supported in v3.
1492 Can you please advise the expectation for categorisation/identification of NPP PayTo transactions under the Consumer Data Standards. Is it expected that these will be identified as NPP transactions or Direct Debit transactions? PayTo mandates are not currently supported as their own data set in the standards. It is at the discretion of each data holder how these should be represented currently based on the way you represented them in other channels. Once the PayTo service has matured this will be raised as a consultation for support within the data standards.
If the executed PayTo mandate results in a transaction on the customer's account then it would be expected to show in the list of transactions.
1505 Field 'displayName' (The name of the tariff period)
(This field sits within 'EnergyPlanTariffPeriod' section of Get Energy Account Detail api)
Qs. Request clarification or details regarding - what this field relates to, in the context of the tariffPeriod.
Any examples regarding same will help.
Note: Below is the non-normative sample:
[
{
"type": "ENVIRONMENTAL",
"displayName": "string", - 'Please clarify'
"startDate": "string",
"endDate": "string",
"dailySupplyCharges": "string",
"rateBlockUType": "singleRate"....		 The contents of the 'displayName' is at the discretion of the DH. It could be aligned to how that charge is displayed on an online channel or an invoice for example.
Here is a knowledge article with similar guidance for the banking sector - https://cdr-support.zendesk.com/hc/en-us/articles/900005430063-BankingAccount-nickname-productName-and-displayName-fields.

Useful Links

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

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally