ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 19th of October 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
teams@vc.treasury.gov.au
Video Conference ID: 133 133 341 4
Alternate VTC instructions Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney Phone Conference ID: 715 805 177# Find a local number | Reset PIN
Learn More | Meeting options

Agenda

Introductions
Updates
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

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.

House Keeping

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 contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.

Community Guidelines

By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.

Updates

⭐ indicates change from last week.

Type	Topic	Update
Standards ⭐	Version 1.27.0	Published: 10th October 2023 Change log
Maintenance ⭐	Maintenance Iteration 17	Met on the 4th of October 2023 Next meet on the 18th of October 2023
Maintenance	Maintenance Iteration 17	All agendas and meeting minutes
DSB Newsletter	To subscribe to DSB Newsletter	Link here
DSB Newsletter ⭐	6th of October 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	No Close Date Link to consultation
Consultation	Noting Paper 307 - LCCD Consultation Approach	No Close Date Link to consultation Video
Consultation	Noting Paper 308 - Categories of Standards	No Close Date Link to consultation
Consultation	Decision Proposal 276 - July 2023 Rules & Standards Impacts	20th October 2023 Link to consultation
Consultation	Decision Proposal 327 - Authentication Uplift Phase 1	24th October 2023 Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation
Video ⭐	80 CDS 1.27.0 Release Walkthrough and Changes - with Jarryd Judd (17/10/2023)	Video
Video ⭐	81 Decision Proposal 327 - narrated by Jarryd Judd (17/10/2023)	Video
Engineering ⭐	Test Data Server has been updated to align to CDS version (1.26.0).	The Github repository
Survey	End of the year! Question to everyone on the Call: When do we want to stop the call in 2023? And when to pick it back up again in 2024? Survey closes: 27th October 2023 Review results: 2nd November 2023	2 question survey CDR Implementation Call 2023-2024

CDR Stream Updates

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

Organisation	Stream	Member
ACCC	Register and Accreditation Application Platform	Eva
ACCC	Conformance Test Suite	Christian
DSB	Consumer Experience	Bikram
DSB	Register Standards	James

Presentation

None planned this week.

Q&A

Questions on Notice

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

In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.

Answer provided

Ticket #	Question	Answer
2063	Hi team, wanting to confirm if there is a CX instruction or requirement of how to treat an ineligible customers by doing one or either of the below: - Not sending an OTP and not allowing them to access the CDR portal or - Send an OTP, allow customer into the CDR portal, but do not display any eligible account?	It is DSB CX’s view that a DH might successfully authenticate a consumer who, if they do not have eligible accounts, could be presented with a list of unavailable accounts and an accompanying explanation, as per the CX Standards (see Authorisation Standards on Unavailable Accounts) and Guidelines.
2107	Hello everyone, we’d like additional clarification on CDS-DC-0008 for the treatment of bulk payment files that can be future dated. Here our customers use Industry Standard ABA and Bulk BPAY files to schedule payments to their vendors and collections from their customers. As these files require approval from multiple stakeholders in their business, they can be future dated. These files are stored at the customer level and not created nor displayed in the same place as scheduled payments are in our customer’s banking portals. Is the intention of the scheduled payments APIs to: - Align with existing digital banking experiences in the treatment of scheduled payments and hence not provide the ABA and Bulk BPAY data, or - Make available any future dated payments provided in bulk, noting this would require significant change in how this information is currently held?	The scheduled payments API are not designed (and as far as I am aware, not intended) to cover bulk payments that are registered for execution. I would not classify these as 'scheduled payments' I would classify these as 'staged payments'. The bulk format is really just a way to deliver a set of complex payment instructions. It is an interesting question that we may bring up with Treasury for policy consideration but I think the clearest position is that staged, filed based, bulk payments do not need to be shown in the scheduled payments API.
2122	I'm wondering how I can get access to usage data. Under the peer-sharing model, it seems like retailers act as the proxy for AEMO. Meaning that if Want to get ahold of interval data, I'd have to go through the retailer. Is that correct? Furthermore, are there any obligations on retailers for making APIs to access this data ? Obviously I can request it from the retailers via email (if I have necesary consent) but it's a very slow turnaround time. It also means data is out of date by the time it arrives etc etc.	Essentially, the entire purpose of the CDR is to require designated data holders (which includes energy retailers) to create APIs, to a defined standard, that can be used to access data on behalf of a consumer. To get access to the data there are some things to be aware of: You must be an accredited data recipient to call the APIs (see https://www.cdr.gov.au/for-providers#goto-information-for-accredited-data-recipients) You must call the APIs according to the standards (see https://consumerdatastandardsaustralia.github.io/standards/#introduction) To call the APIs you must obtain consent from a customer. You can't get the data without explicit customer consent (see https://www.cdr.gov.au/how-it-works) Usage data is provided by AEMO who gets the data daily. You call the energy retailer to access this data, however, as customer consent is required and only the retailer knows the customer.
2123	When including the green power tiers for a customer's contract, is the schema EnergyPlanGreenPowerCharges meant to include all available tiers or just the tier that customer has selected? For example, if the available green power tiers are - 10% - 50% - 100% and the customer is on the 50% tier. Should we return all 3 tiers or just the 50% one?	You would only include the tires that are applicable/selected for the customers account as the context is about the customers current plan/account. If it were PRD information (e.g. Get Generic Plan or Get Generic Plan Detail), it would include all the avaible tires for the given plan.
2125	With reference to Decision paper # 57, 'description' field in Banking Direct Debit schema was supposed to have been made mandatory. However, the CDR schema definition in https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingdirectdebit show it as optional. I have tried to search on zendesk for any subsequent decision paper if description was made optional again since decision paper # 57, but I couldn't locate anything that overruled decision paper #57 for the optionality of 'description' field. Are you able kindly able to help me understand why description is still optional despite decision paper #57?	This field was defined during the very early days of the CDR when there were a lot of concurrent consultations and in person workshops. There were many fields that were initially defined and then subsequently modified during this period. To accommodate the flux that was occurring, when we published v1.0.0 of the standards the Chair made a formal decision in consultation with the DSAC to approve the standards as published so v1.0.0 became the baseline. From memory, the reason the field was made optional is becuase direct debit authorisations are not held by the banks and have to be derived by scanning transaction histories for BECS direct debit transactions. If the additional detail for the merchant initiating the direct debit isn't included in that transaction then the bank can't provide the description in any meaningful way.
2126	I'm assuming the options for the EnergyPlanContractV2 pricing model e.g. SINGLE_RATE, SINGLE_RATE_CONT_LOAD etc are based on the Energy Made Easy spec. However EME doesn't deal with C&I customers. I've attached some large business tariffs that I don't think fit into any of the current pricing model options. Has this issued been raised before?	I believe the pricing models were based off EME initially and, through consultations, changed as per community input. No feedback/issue has been raised so far for them not working for C&I consumers in our consultations, including C&I specific ones (that doesn't imply there is are no gaps). I'd suggest raising a CR for this issue which we can consult on in future MI (current one is already halfway through i believe).
2128	Can individuals access the https://consumerdatastandardsaustralia.github.io/standards/#get-data-holder-brands API, what is the Authorization header that is required?	Yes the Get Data Holder Brands endpoint is public and can be accessed. You just need to provide the mandatory x-v request header. Here is an example curl: curl https://api.cdr.gov.au/cdr-register/v1/all/data-holders/brands/summary --header x-v:1
2129	I believe the fees to be provided as part of the Get Account Detail must be linked to a given account while the fees to be provided a part of the Get Product Details is general to a given product. For loans application, potential customers must pay a once-off upfront fee to check if they are eligible for the loan application. This fee is taken regardless of whether the application is successful or not. The customer can pay this once-off fee using cash or funds from another bank. The application and upfront fees are recorded in a separate system to our core banking system. If a loan application is approved and accepted, then the loan account will be setup in our core banking system. This loan account has no linkage to the loan application where the initial upfront payment was received. Since there's no linkage between the loan application and our core banking system via a unique identifier such as the loan account number, are we expected to return this once off fee by hardcoding it into the Get Account Detail API ? The risk I can see with that are : 1. The fee may come from another bank 2. The actual upfront fee paid by a customer could be different to the general assumed hardcoded fee 3. The customer may be exempted from the fee	I think much of what you have asked has been asked before so I will refer you to those articles for consistency of response. If they don't address your questions let me know. https://cdr-support.zendesk.com/agent/tickets/166 Q: Also, how far back historically do we need to provide fees for? I.e. if a home loan settled 15 years ago and therefore the settlement fees were charged 15 years ago, do we need to provide those as well? A: No. If the fee will never be charged again (for instance, an establishment fee) then it does not need to included. More detail here in the implementation call minutes against ticket 166: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-%26-DSB-%7C-CDR-Implementation-Call-Agenda-%26-Meeting-Notes-(24th-of-September-2020) and here: https://cdr-support.zendesk.com/agent/tickets/1061 All fees should be included if they are going to be incurred in the future. Past fees that will no longer recur are not in this category. For instance, a break fee should be included but an establishment fee for an account that is already established does not need to be included. published here in the minutes against '1061': https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-%26-DSB-%7C-CDR-Implementation-Call-Agenda-%26-Meeting-Notes-%7C-16th-of-September-2021
2130	Questions about conformance testing with a client under outsource arrangement We have a number of question with regards to how we can support clients that are already ADRs via a Outsourced Provider model and how this will work in practice in relation to Conformance Testing and production go live for CDR under such a model. Just some quick background first: * We are already an ADR and has previously itself already passed Conformance Testing Suite (CST) with its Open Banking Platform (OBP) software product and activated with CDR on production. * OBP is designed to operate as a multi-tenant application, i.e. where a single running instance of the application is shared between the clients. * We now have a new client coming onboard (who are already an ADR) and they wish to go-live for CDR, we are acting as their outsource provider via OBP. * The client has already designated a developer as a Authorised CTS Tester in the CDR Participant Portal, presumably so we can manage and update progress for CTS on the client's behalf. So is our understanding here correct that: 1. Will the client need to submit via the CDR Participant Portal the certificate signing requests (CSR) to register for CTS, where we will provide the CSRs for OBP it will be running the CTS against? 2. I assume this also means that wealso provide all the product endpoint details for which the client will be submitting as of the CSR request submission? 3. The CSRs for client/server certificates to be issued for the client will need to contain the client's own brand name as the 'Organization' (and not ours)? 4. Will there be a different 'Data Recipient Brand ID' and/or 'Software Product ID' issued for the client (separate from the one that was issued to us)? 5. When weOBP triggers the CDR registration request (for CTS and activation in CDR on production) for the client is sent – should this likewise utilise the newly issued 'Data Recipient ID' and/or 'Software Product ID'? We would appreciate if you will be able to provide some clarification for these questions	* The client has already designated a developer as a Authorised CTS Tester in the CDR Participant Portal, presumably so wecan manage and update progress for CTS on the client's behalf. Answer: The CTS tester is able to submit the CTS enrolment form, view and update the CTS authentication and CTS endpoint details, and view CTS certificates as well as conduct CTS testing on behalf of the participant. So is our understanding here correct that: 1. Will the client need to submit via the CDR Participant Portal the certificate signing requests (CSR) to register for CTS, where we will provide the CSRs for OBP it will be running the CTS against? Answer: Correct, if we only has access to the participant’s Portal as a CTS Tester, then the participant will need to submit the CTS CSR. 2. I assume this also means that we also provide all the product endpoint details for which the client will be submitting as of the CSR request submission? Answer: This is correct. 3. The CSRs for client/server certificates to be issued for the client will need to contain the client's own brand name as the 'Organization' (and not ours)? This is correct. Since the client is an ADR and the SP is going to be listed under their own legal entity, hence in the register APIs the responsible organisation will be the parent Brand which should match the value in the client certificate (ref: certificate-management). 4. Will there be a different 'Data Recipient Brand ID' and/or 'Software Product ID' issued for the client (separate from the one that was issued to us)? Answer: Correct as they have a new brand/ software product and therefore new ID numbers for them. 5. When our OBP triggers the CDR registration request (for CTS and activation in CDR on production) for the client is sent – should this likewise utilise the newly issued 'Data Recipient ID' and/or 'Software Product ID'? Answer: Yes, we recommend utilising the new Software product ID issued since the Data Recipient Brand ID is soon to deprecated as notified by the Standards (ref: DSB DR Brand ID notification).
2133	Referring to the Zendesk article (#1845) https://cdr-support.zendesk.com/hc/en-us/requests/1845, Errormetrics need to be only based on 5xx error (not 4xx). But in the JSON sample referring (Decision.288.-.Nonfunctional.Requirements.Revision.pdf) we could see 406 also included. "errors": { "aggregate": { "currentDay": 305, "previousDays": [245, 345, 543] }, "authenticated": { "currentDay": { "500": 12, "406": 83 }, Could you please clarify the intention, so we can align Get Metrics V4 as per the standards.	I think I addressed this on an implementation call recently. The aggregate field is intending to be a carry forward of the previous v3 errors field so should only include server errors and not client errors (ie. just keep your previous implementation for this field). The new object should include client and server errors as we would like to obtain this detail to understand what is happening in the ecosystem and this data would be very helpful in that goal.
2134	In the Decision.288.-.Non-Functional.Requirements.Revision.pdf, the previousDays value are represented. Could you please clarify the representation that the Data Holder would need to follow.	Definitely build according to the published standards. The reference sample in the decision document was only a sample. The decision statements in the body of the decision have been adhered to.
2135	We would like to confirm that for amendedAuthorisationCount in the Authorisationmetrics only below scenarios are required: 1. Amend the datasets being collected (requires re-authentication or authorisation) 2. Amend the collection duration (requires re-authentication or authorisation) 3. Amend the accounts associated with the consent/authorisation (the consumer could amend these in the authorisation flow). As a DH we are also providing the optional functionality to add or remove the consented accounts via DH consent dashboard. This scenario we assume not to be counted under the above amendedAuthorisationCount. Please confirm.	These metrics were only intended to cover a customer going through the consent authorisation flow. An amended consent is technically when a consent is authorised but a pre-existing arrangement ID is provided by the ADR. Changing account associations with a consent or changes in joint account authorisations, etc are not considered consent amendments. I think it's awesome you are letting customer change their accounts in the consumer dashboard but this shouldn't be included in the amendedAuthorisationCount metric.
2136	Under abandonmentsByStage, we presume the following meaning, could you please confirm: "rejected" - means consumer canceling the authorisation process using 'cancel' button in the UI screen irrespective of the stage. Example a consumer can cancel authorisation process during any stage such as preauthentication, preidentification, preaccountselection or preauthorisation etc.). "abandoning the process" - means consumer closing the browser or session expired etc. based on the stage. Example a consumer closed the browser while on preauthentication screen.	Yes. That's what is intended for abandonmentsByStage.
2140	I was wondering about the requirements under the "Participant Statuses" section of the specs. It says "Data Holders will poll the Get Data Recipients Statuses, Get Software Products Statuses and Get Data Recipients APIs to retrieve the current statuses and cache these for use during requests for Consumer Data". However, in the specs under "Admin API" there is a "MetaData Update" API that "Indicate that a critical update to the metadata for Accredited Data Recipients has been made and should be obtained". Could you please elaborate on the need for DH to poll when updates to an ADR is relayed to a DH through the "MetaData Update" Admin API? Also, it would be help ful if you could elaborate on the different use cases.	The design intent is that statuses only need to be updated and cached by data holders every few hours and if anything urgent happens then the meta data update API will be called by the Register and data holders must refresh immediately. Unfortunately the Register has not yet built this functionality so they request that data holders call the status endpoints every five minutes.
2142	v4 is improving the way availability, error metrics and TPS data is reported by splitting them into unauthenticated and authenticated end points. Since that split was not previously done by DH, there is no historic data in same format. How does ACCC expect historic data be reported especially for availability where data goes back 12 months. Other metrics will take 7 days to pick up post go live but availability will take 12 months. Previous data is also restricted to be number between 0 -1. How does DH report unavailable historic data?	At the request of the ACCC we have also included aggregate fields that have the same definition as the previous v3 fields. These will allow history to be maintained.
2144	Can you please point a way to track the changes of the draft NBL standards at https://consumerdatastandardsaustralia.github.io/standards/includes/additional/drafts/non-bank-lending/banking-non-bank-lending.html#high-level-standards against the respective 1.27 standards? As far as I can see the version delta has not been updated and also can't see changes in Github as the draft standards are a new page. A side by side comparison of the pages does seem the most efficient way.	The draft NBL standards were only just introduced so there are no deltas on the draft standards yet. We have included a delta tab on the draft standards, however, for further changes.
2145	I would like to know in the context of metrics v4 and above, in the authorisations metrics section, should the consents whose sharing duration is less than or equal to 24 hours considered as a onceOff consent or an ongoing consent? In this[1] section of the specification, it says consents with sharing duration less than or equal to 24 hours should be considered as one-time collection. Please provide clarification on the above. [1] https://consumerdatastandardsaustralia.github.io/standards/#request-object	Yes, the definition of a one-time or once-off consent is a sharing duration of 24 hours or less. This is the defintion that should be used for metrics.
2146	I would like to know in the context of metrics v4 and above, for the error metrics under each aspect(authenticated and unauthenticated) we are supposed to include 4xx errors. I would like to know if we should return the error counts of 429 status code here as well since we are already providing them under the rejection metrics? Also are there any specific error status codes that should or should not be shown under the error metrics?	The aggregate field should operate like the v3 errors field and should only include server errors. The new structure with the HTTP response codes should include both client and server errors.
2078	We are a CDR data recipient is requesting clarification on the PAR request and subsequent auth call. We have had a recent incident with a Data Hlder where the nonce (a one time token) associated with PAR request was required to replayed through the following Auth request. We are seeking clarification on the standards in this regard as it seems unusual to reuse the nonce. We have updated our requests to do so but given this only impacted we are checking whether their interpretation of the standards in accurate.	I may be misunderstanding the scenario so please correct me if that's the case. If I understand it, you as the oAuth client is generating a nonce and then sending it in the request object lodged via the PAR endpoint. This nonce is then carried through the authentication request and replayed in the ID Token. If that is the case it would be per spec for OIDC. It is a security property to allow the client to verify against replay attacks and it is up to the client to verify the value they receive is the same one they sent. Cycling the nonce is the responsibility of the client. And you are doing the correct thing my sending it. As per FAPI 1.0 Basic section 5.2.2.2, the nonce is required whenever the openid scope is requested. Also in accordance with RFC9126 (PAR) section 7.5 I expect you are sending a code challenge because PKCE is required to be supported with Authorization Code Flow so there are two properties performing a similar function.
2036	Following up from this can I conclude that below holds true. For the auth code flow, the mandatory parameters are: 1. RequestUri 2. ClientId And for the hybrid flow, the mandatory parameters are: 1. ClientId 2. Scope 3. RequestUri To clarify "scope" is not applicable to the auth code flow. Please correct me if I'm wrong.	Apologies for the delay in responding. We needed to do some checking before responding. The Consumer Data Standards define the behaviour of the authorisation endpoint as aligning to the section 3.3.2 of the ODIC normative standard. This, in turn refers to section 3.1.2 (https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). Section 3.1.2 states that all four of the parameters in the question are required. The Consumer Data Standards also refer to the section 5.2.2 of FAPI 1.0 Advanced. This section does constrain the implementation of the authorisation endpoint but does not chnage the mandatory status of the four parameters in question. In the transition from Hybrid Flow to ACF the mandatory nature of these fields does not appear to change in the normative standards. The DSB would therefore see the scope, response_type, client_id and redirect_uri parameters as all being required when calling the authotisation endpoint.
2013	Currently, there is conflicting information in the standards about the ID token claims 'sharing_expires_at' and 'refresh_token_expires_at'. The ‘Token Expiry’ section states these claims may be retired from 16th September, however, the ‘Scopes and Claims’ section lists that these claims must be supported. We found that few of the providers are not supporting sharing_expires_at claim as part of token response(grant_type=authorisation_code). In absence of this claim in token response we are unable to identify the expiration date of sharing durationn. Also came across this link https://github.com/ConsumerDataStandardsAustralia/standards/issues/209, where the pdf document "Decision.209.-.Transition.to.FAPI.1.0.Advanced.Profil" mentions below. 1. (c) Should CDR token response parameters be registered or otherwise moved out of the parent token endpoint response JSON / ID token JWT? If so, where should they be moved to for better Identity & Access Management (IAM) software supportability? • Feedback identified that the "sharing_expires_at" and "refresh_token_expires_at" claims can be retired once refresh token cycling has been deprecated. This would simplify the token response and remove redundant claims. The normative "exp" claim would repres However unable to identify where should be looking for the 'exp' claim. We looked at the exp claim which is part of id_token and found that to have a values which is much shorter than the requested sharing_duration. Hence can you guide us on specific end point/api whihc will have this value?	The expiry of the provided refresh token must now align to the expiry of the overall authorised consent. This expiry can be obtained via the 'exp' claim retrieved via the introspection endpoint when called with the refresh token.
2139	RE: Amending Rules (No. 1) 2023, Rule 1.15(3)(h) 1. As a Data Holder, we are seeking clarity on what information must be available via the Dashboard, and also whether this is expected to be a marked up version of the historically endorsed amendment? 2. Will, and when will supporting artefacts be published for this change?	Rule 1.15(3) sets out the information that must be displayed on a consumer dashboard for each authorisation. From 1 July 2024, this information includes the details of each amendment that has been made to the authorisation (see rules 1.15(3)(h) and 1.15(3A)). The DSB is currently consulting on new standards to give effect to rule 1.15(3)(h) – see Decision Proposal 276 on page 6. The Decision Proposal outlines the impacts to the Standards and CX Guidelines as a result of the latest amendments to the CDR Rules. The consultation will determine the appropriate options and scope of data standards to be made, including how data holders should display amendments to authorisations on a consumer’s dashboard. The consultation also references an existing CX Guideline wireframe to provide a visual example of how authorisation amendments could be displayed on a data holder's dashboard (see footnote 22 on page 6). Feedback in response to Decision Proposal 276 is due by 20 October 2023. The DSB also invites the community to request new or amended CX Guidelines on the DSB Standards Maintenance site.