ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 8th of December 2022
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
[email protected]
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
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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.
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.
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.
| Type | Topic | Update |
|---|---|---|
| End of Year | 1st of December 2022 8th of December 2022 15th of December 2022 Last Call for 2022! |
Thank you to everyone for a great year! |
| CDR Implementation Call 2023 | Commences 19th of January 2023 | Invitations to be updated and sent out |
| Standards | Version 1.20.0 Published on 3rd of November 2022 | Link to change log here |
| Standards | Version 1.21.0 is being prepared | ETA is mid December 2022 |
| Maintenance | Maintenance Iteration 13 change window concluded | Met 23rd of November 2022 and the agenda for the meet is here |
| Maintenance | Decision Proposal 272 - Maintenance Iteration 13 | Changes, meeting notes and updates for the iteration can be found here |
| Maintenance | Retrospective for MI13 to be held 14th of December 2022 | Invitations have been sent |
| Maintenance | Iteration 14 to Commence on 8th of February 2022 | Invitations to be sent |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | 3rd of November 2022 | View in browser here |
| DSB Newsletter | 25th of November 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 |
| Noting Paper | Noting Paper 255 - Approach to Telco Sector Standards | Link to consultation |
| Noting Paper | Noting Paper 258 - Independent Information Security Review | Link to consultation |
| Consultation | Decision Proposal 267- CX Standards Telco Data Language Feedback closed: 15th of September 2022 Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October. Reopened for feedback until the 9th of December 2022 |
Link to consultation |
| Consultation | Noting Paper 273 - Consent Review |
Feedback closes: 9th of December Link to consultation |
| Consultation | Decision Proposal 275 - Holistic Feedback on Telco Standards | No Close Date Link to consultation |
| Consultation | Noting Paper 276 - Proposed v5 Rules & Standards Impacts | No Close Date Link to consultation |
| Feedback | If the CDR Community are able to provide feedback on this banking-related item from Maintenance Iteration 13: Specify if an Account is a joint account in the API response #513 | The DSB are looking for feedback by end of 9th of December 2022 |
Provides a weekly update on the activities of each of the CDR streams and their stream of work
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register | Christian Cipressi |
| ACCC | CTS | Preeti Patel |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking and Info Security | Mark Verstege |
| DSB | Technical Standards - Energy | Hemang Rathod |
| DSB | Technical Standards - Telecommunications | Brian Kirkpatrick |
| DSB | Engineering | Sumaya Hasan |
No presentation planned this week.
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.
| Ticket # | Question | Answer |
|---|---|---|
| 1621 | This is a follow up question to this article: https://cdr-support.zendesk.com/hc/en-us/articles/4412307405711?input_string=requesting+energy+usage+across+multiple+participant+ids In the event a data holder has to issue multiple requests to AEMO to serve a single ADR request, a data holder is effectively unable to leverage the pagination provided by AEMO. What is likely to happen is retailers would need to load the entire usage data from AEMO and perform their own server side pagination on the aggregated data set. Can DSB or AEMO provide recommendations for handling this use case please? Thanks |
I believe this question was answered in one of the implementation calls. To re-iterate, the DH can request the first page for a NMI/participant ID which would contain totalPages and totalRecords which can be used to determine the necessary pagination in the response to ADR. |
| 1631 | In relation to AEMO SR data for open energy, rule is that the data must not be stored in data holders environment and that once shared it must be deleted (therefore no point storing). Does this mean pass-through model of data flow is what we expect. Also, Is there a timeline definition of short-lived cache is as mentioned in the consumer data standards body website for this data. It says to be able to manage network efficiency using normal mechanisms, a data holder making SR data requests may cache the results from the Secondary data holder for a short period of time to accommodate repeated duplicate calls from DR software Please clarify what is the min compliance requirements, No storage, could cache or preferably pass-through? |
The standards do not prescribe any minimum caching requirements. Its up to the determination of data holder if they wish to implement a short term cache for network efficiency/optimising performance , as long it’s a non-persistent short lived cache and data can’t be used for other purposes in alignment with the rules. |
| 1654 | In the CDS specification (link below) - https://consumerdatastandardsaustralia.github.io/standards/?examples#energy The below requirement states that multiple API calls could be made parallelly with AEMO. "Some primary Data Holders may interact with AEMO using multiple participant IDs. For these Data Holders it is possible that a single request from a CDR Consumer covering multiple NMIs would require multiple calls to AEMO if the NMIs were associated with multiple participant IDs owned by the Data Holder. In this scenario the retailer MUST call AEMO multiple times and aggregate the results before responding to the Data Recipient" Considering Rate-Limit is an allowed number of parallel calls from one source at a given period of time. What is the max Rate Limit allowed for any Secondary AEMO APIs? |
The standards have not defined any TPS or rate liming NFRs for AEMO. The expectation is any rate-limiting would be managed through the DH/retailer NFRs. In other words, AEMOs traffic protection is via protections given to a retailer via the NFRs in the standards. We could potentially look at introducing TPS requirements for AEMO if required based on real usage data. |
| 1757 | Given a scenario, when the NI removes last remaining NR from the account and NR have an active consents for that account. Due to some reason that consent(s) are not withdrawn by the NR via consent dashboard and NI is not provided with the consent dashboard either and NI can only use the manual process to withdraw the consent, which may be not be at the same time when the last NI was removed. Hence, CDR data sharing will continue until all the consent are removed. For example, last NR associated with the account was removed on say 1 September 2022 and consent withdrawal request was received and processed on 20 September 2022. So technically, there was no NR associated with account for 20 days and CDR data was shared during that period Questions: Is this the breach of CDR Rules as there was no NR and CDR data sharing continued during that period? |
The purpose of a nominated representative is to allow a CDR consumer to “give, amend and manage authorisations to disclose CDR data that relate to the non-individual [or] …partnership accounts” (see CDR rules 1.13(1)(c) and (d)). We recognise that there may be circumstances where an ongoing authorisation remains in place after the last (or sole) nominated representative has been removed from an account. In these circumstances, our view is that a data holder would not be in breach for continuing to disclose data in accordance with a valid authorisation. This is because the business is the CDR consumer (rather than the nominated representative), and the ongoing authorisation was put in place on its behalf. In circumstances where a business consumer is removing all nominated representatives, our view is that the data holder should encourage the business consumer (and/or the departing nominated representative) to withdraw all active authorisations. Alternatively, the business consumer may elect to appoint a new nominated representative. |
| 1800 | Are there any implications on DCR to support JARM? I noticed that we didn't include any registration claims to determine JARM signing and encryption algorithms. Do we just assume the values provided in the following fields? id_token_signed_response_alg id_token_encrypted_response_alg id_token_encrypted_response_enc I also wanted to validate: - is id_token encryption still required for JARM, given that the id_token isn't a detached value anymore? - is JARM encryption required or optional? On second look, it looks like id_token encryption is optional when looking at the token endpoint requirements. This is out of line with the registration requirements, where it requires the following, and there is nothing to tell the ADH that id_token shouldn't be encrypted: - id_token_encrypted_response_alg - id_token_encrypted_response_enc We found the client metadata requirements in the openid JARM standards. We are assuming we will implement the following: id_token_signed_response_alg (REQUIRED) id_token_encrypted_response_alg (OPTIONAL when JARM is enforced) id_token_encrypted_response_enc (OPTIONAL when JARM is enforced) authorization_signed_response_alg (REQUIRED) authorization_encrypted_response_alg (OPTIONAL) authorization_encrypted_response_enc (OPTIONAL) |
Given the ID token acts as a detached signature for the OIDC Hydrid Flow but not for the Authorization Code Flow the ID Token metadata values are only required for OIDC Hybrid Flow. You are correct that the authorisation response signing algorithm is required for Authorization Code Flow (with JARM) whilst the encryption metadata values are optional. |
| 1806 | As an ADR, we have seen the following fields change for the same POSTED transaction retrieved a day apart. - description - merchantName Is this allowed? The bank offers the user the ability to change the Merchant Name, and this changes the description. |
There is nothing in the Rules or Standards that would prohibit changes to transaction data like that, and in most cases we have suggested that any data shared through CDR should match what is provided to the consumer through other channels. Does that behaviour cause a particular problem for your use of the data? You may find the following articles relevant to your question as well - Pending and Posted Transaction duplication Can Data Holders match Pending and Posting Transactions? |
| 1807 | Should a balance record for a credit card account retrieved via the API have the creditLimit field populated? We have seen banks using the currentBalance as outstanding Pending transactions and Available balance as amount left to spend (up to creditcard limit). But this doesnt give an indication on what is the actual credit card balance. ie if I have $95.00 left to spend, there is a difference in what my credit card balance is if my creditLimit is 100 over if it is 10000. | See Appendix |
| 1809 | Taken on notice from the CDR Implementation Call 24th of November 2022. Are pairwise id per ADR-Software? Or per sector-id (which is the OpenID Connect approach). ID permanence, is that really done per adr software or does it use the sector id uri functionality that openid net provides Whole point of sector id uri, was to allow pairwise ids for sector applications, which sounds like what Which sounds exactly what ID permanence is about. But but other parts of the spec talk about it being, you know, per software. So I was just curious as to how it actually works in practice. |
Question: Are pairwise id per ADR-Software? Answer: ID Permanence and Pairwise Identifiers are two different things. Sector Identifier URI can be used by the ADR to group a set of domains under common administrative control. Sector Identifier URI relates to the pseudonymous pairwise identifiers (PPID) representing a user subject. PPIDs can be represent in two ways: 1. PPIDs per individual oAuth clients (ADR Software Product) 2. PPIDs per sector identifiers or "client groups" ID Permanence on the other hand pertains to the resource identifiers within sectorial domains defined in the CDR Data Standards. ID Permanence requirements relate to the consumer, not the authenticated end user (unlike the "sub" claim which is an OIDC term). This means that for the one consumer represented by many nominated representatives, the same identifiers are issued to the ADR (because they consumer is the same across the nominated reps). In the scenario where the individual consumer is the authenticated end user this amounts to only one "sub" value related to the resource identifiers. |
| 1813 | We would like to confirm if instalment payment plans such as Afterpay should be included in the GetDirectDebit API response. Per this article and the links to other articles it contains - https://cdr-support.zendesk.com/hc/en-us/articles/900004589866-Direct-Debit-definitions - it appears that 'instalment payments' meet the definition. There is an external merchant (so these are not 'internal transfers'), the merchant has been given authority by the account holder to debit their account (whether via, say, the BECS/Direct Entry channel, or via a credit / debit card in the EFTPOS channel), for a specific number of payments, for specific values. Please confirm. |
From what you've described, it does appear that these could be considered as 'authorisations' for 'debits' and would be appropriate to include in the Direct Debit APIs. Note though, that the Direct Debit API is intended to contain details about an authorisation given, not all the transactions that may result from one. With that in mind, the entries you've described could be considered valid if they are 'authorisations' (if that's how you store or infer them). It's not because they are 'instalments', 'plans', or even recurring. |
| 1819 | Is there a document that depicts the lifecycle of a Consumer data request covering Consumer, Data Recipient, Data Holder, Register and Secondary Data Holder interactions. The objective being the ability to communicate the roles of the various APIs in that lifecycle |
You can find a sequence diagram of the Consent sequence diagrams and we have a video: https://youtu.be/bs-EA3Qc5T0 In terms of a comprehensive end to end diagram. I am not aware of one but I will ask the team. |
As the standard states though, if that property is absent, you may assume the limit is zero, and that may be the intention of the Data Holder.
That may be the case if the account was actually a debit card for example, or may have been interpreted as the card not having a predefined limit (though this may be in conflict with having an availableBalance greater than zero for a credit card).
Ideally, a Data Holder may provide values for a card with -
- 10000 limit (creditLimit)
- 9905 spent (negative currentBalance if money owing)
- 95 left to spend
in this form -
| currentBalance | -9905 |
|---|---|
| availableBalance | 95 |
| creditLimit | 10000 |
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
That may be the case if the account was actually a debit card for example, or may have been interpreted as the card not having a predefined limit (though this may be in conflict with having an availableBalance greater than zero for a credit card).
Ideally, a Data Holder may provide values for a card with - 10000 limit (creditLimit) 9905 spent (negative currentBalance if money owing) 95 left to spend
in this form - currentBalance -9905 availableBalance 95 creditLimit 10000