ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 12th of September 2024
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
- 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 and present, 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.
⭐ indicates change from last week.
| Type | Updated | Links |
|---|---|---|
| Standards | Version 1.31.0 | Published: 3rd of July 2024 Change log |
| Maintenance | Iteration 20 Completed 4th of September 2024 |
Sign-up and Register Data Standards Body Events |
| Maintenance | Iteration 20 Schedule: |
MI20 Agendas and Minutes |
| Maintenance | Iteration 20 Decision Proposal | Link to DP353 |
| Maintenance | Iteration 21 commences on the 18th September 2024 Sign up now open |
DSB Calendar |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 6th September 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Noting Paper 351 - LCCD Risk workshop summary | No feedback sought Link to Noting Paper |
| Consultation ⭐ | Noting Paper 355 - Deceptive Patterns Independent Health Check | No feedback sought Link to Noting Paper |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Alexey |
| DSB | Consumer Experience | Michael |
None 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 |
|---|---|---|
| 2392 Part 1 | As a dataholder providing a DCR service we perform some basic SSA validations on the registration payload, one of these is validating that the various URIs provided as part of the DCR request are https - and not http ( client_uri, redirect_uris, logo_uri, jwks_uri, etc) This is in line with our cyber policy as well as the standards 1) All normative examples for DCR have https:// https://consumerdatastandardsaustralia.github.io/standards/#client-registration 2) Transaction Security All HTTP calls MUST be made using HTTPS incorporating TLS >= 1.2. NOTE - On the standards websites - all examples for URIs are https 3) Validations on CDR Sandbox tooling also enforce https a) Would like to seek clarification as to why does the URI String example use http? https://consumerdatastandardsaustralia.github.io/standards/#common-field-types URIString A valid URI "http://www.google.com/" (This is the only spot where http:// has been used as an example) Also - we believe the Register should also enforce the use of https as part of the on-boarding when the ADR's brand is set up in the register. It seems that there is at least an example of one ADR's brand registered with ACCC using http:// for their various URI endpoints and our Auth Servers SSA validation will reject their request based on the fact that the URI's are http:// Allowing http could pose a risk to our systems We believe that The ADR should update their registration properties to use https:// instead of http rather than requiring dataholders to support http for URI endpoints Any guidance on the way forward and the approach towards the use of http in the URIs will be greatly appreciated |
I've raised a request to change the URIString example in the current Maintenance Iteration. I don't believe there was a particular reason the example used 'http', other than it being a generic URI. My thinking in how some of the DCR fields relate to the overall requirements for transaction security is that the client_uri and logo_uri for example, are not directly involved in data sharing, but as you've stated, the logo_uri could cause a security concern or policy warning if integrated into an https web page in part of the process. The redirect_uri and jwks_uri could be a different type of concern. Can you clarify for which field the ADR provided an http URI, and whether you have asked them to change it to https? (and, if they weren't able to do so, if they had any specific reason?) You could also refer the ADR to FAPI TLS considerations, which states: all interactions shall be encrypted with TLS (HTTPS) |
| 2392 Part 2 | We have been dealing with an incident in the CDR Portal whereby a client of an ADR is unable to complete DCR due to their client_uri information having a http address - despite their own website utilising https. We had requested they have their client update their registration information to ensure the use of https, with all the supporting references to the use of https/TLS in the standards .. but received considerable pushback on this request from the ADR. Their reasons are such that the Consumer Data Standards do not stipulate the use of https as a requirement. After much consultation with our cyber security team, our Bank’s position is that accepting https will weaken our security position as an organisation and present vulnerabilities to our customers and potentially the ADR’s client as well. The ADR in question is currently taking the position that they will not support our customers in their client’s platform due to this reported issue and are therefore at a standstill with this issue. Please note that this is not due to any technical constraints on their platform. Thanks again for your inputs with this. Clarification in the standards will be great so that we can encourage them to update their client's registration details which is fairly straight forward. May be also good if the register on-boarding processes are also updated to not allow an http URL as well? |
The URIString example will be updated in the next version of the Standards and your comment regarding onboarding requirements has been passed on to the ACCC. Whether the ADR decides to update their details and re-attempt registration with you would ultimately be at their discretion. |
| 2399 | The postingDateTime field in the standards for a Banking Transaction is defined as a DateTimeString. The standards further state that this field should be interpreted as follows - “As specified in [RFC3339] times MUST be offset relative to UTC”. We have identified at least one DH who doesn't store a time component for this field in their core banking system. As a result, they are doing the following 1. Taking the date from their core system 2. Appending a static "00:00:00" to the end 3. Not including any timezone/offset information For example - they are passing values such as "2024-07-22 00:00:00". Since there is no offset, we are interpreting this as a UTC value, and as such, when converting it to AEST it's being treated as "2024-07-22 10:00:00". We believe that this DH has incorrectly implemented the standards and require your guidance. |
If the dates are intended to be interpreted as at AEST, then they would be expected to be specified with an offset to that effect, such as: 2024-07-22T00:00:00+10:00 The Z suffix may also be used but the time must be specified as at that offset. i.e., 2024-07-21T14:00:00Z would be the same time as above. Let me know if those examples make sense. If you think the examples in the Standards could be improved let me know or add a comment on the maintenance holistic thread. If you need a compliance view from the ACCC, the ACCC Jira may be the best place to follow up. Further see Issue 658 for a close out of the discussion. |
| 2401 part 1 | There are fields defined in the BankingTransaction as being of the String or AsciiString data type. The definitions for these data types do not explicitly approve or deny that empty strings are permitted. We are seeing some data holders pass us a "description" attribute for transactions as an empty string. Can the DSB recall if this was left loose on purpose, or if there is an expectation that a field such as "description" which is listed as mandatory in the standards should infact NOT permit an empty string value. |
The Empty/Null Fields section states: _ An empty string (“”) is not considered to be equivalent to null._ And the mandatory reference field in BankingTransaction (and a couple of others) states: Empty string if no data provided. This is to allow for Data Holders that do not have a value for that field to return a schema-compliant response. i.e. To provide the field with an empty value, which is different to a null value, being equivalent to an absent field. As the description field doesn't include that statement it could be argued that an empty string is not allowed, but the Data Holder may have valid reasons for it. i.e. the customer did not provide a description. In some cases, how the description is presented in other channels may be a consideration (e.g. if they show some default text). Are you finding that these Data Holders always provide an empty string, or only for certain products, or is it indeterminate? If there is a compliance concern, it could be something the ACCC could review in the first instance, otherwise a Standards Maintenance issue could be raised to clarify the standards expectation. |
| 2401 Part 2 | The specific issue we are investigating is as follows: The DH is providing an empty string In Internet Banking for the DH, a value is provided When we queried the DH, they claimed that their Internet Banking platform has special logic that computes a description out of other values on the transaction when the description is empty. It’s my opinion that if their Internet Banking is computing a value then their OB implementation should be doing the same. Instead, the DH is suggesting that the ADR must compute a useful description. |
That seems like a pretty clear compliance issue. The transaction description is a mandatory field and should be "The transaction description as applied by the financial institution." In general, most data is expected to match other channels so it would be familiar to the consumer. |
| 2414 | The ACCC stated an intent to introduce the automatic provisioning of certificates for ADRs. Is this still the case? And when can we expect it? | The ACCC is still considering introducing certificate automation and hopes to further analyse the work involved in this change soon. We will keep stakeholders updated on proposed timing. |
| 2416 | Population of "city" property in CommonSimpleAddress schema Reference: CommonSimpleAddress schema (a screenshot is attached as well) https://consumerdatastandardsaustralia.github.io/standards/index.html#cdr-common-api_schemas_tocScommonsimpleaddress Scenario: Let's say an international physical address has got both city and locality (suburb/town) values available in an entity's core business system. For example: City value stored as NAPIER Locality (suburb/town) stored as ONEKAWA Question: For the above scenario, which one of the following approaches is recommended as part of Get Customer Detail API and Get Account Detail API responses? >> Send "city" property value as "ONEKAWA" by completely ignoring City (OR) >> Send "city" property value as "NAPIER" by completely ignoring Locality (OR) >> Send "city" property value as "ONEKAWA, NAPIER" by including both Locality and City It would be helpful if there is any guidance article available around this particular question for reference. Thanks in advance for your response/guidance. |
See Appendix |
Have you considered something like below? Does this make sense?
| city | Name of the city or locality | ONEKAWA |
| state | Free text if the country is not Australia. If country is Australia then must be one of the values defined by the State Type Abbreviation in the PAF file format. NSW, QLD, VIC, NT, WA, SA, TAS, ACT, AAT | NAPIER |
| country | A valid ISO 3166 Alpha-3 country code. Australia (AUS) is assumed if country is not present. | NZL |
I think this would be similar to something like:
- Parramatta
- NSW
- AUS
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
city Name of the city or locality ONEKAWA state Free text if the country is not Australia. If country is Australia then must be one of the values defined by the State Type Abbreviation in the PAF file format. NSW, QLD, VIC, NT, WA, SA, TAS, ACT, AAT NAPIER country A valid ISO 3166 Alpha-3 country code. Australia (AUS) is assumed if country is not present. NZL
I think this would be similar to something like: Parramatta NSW AUS