When: Weekly every Thursday at 3pm-4:30pm AEST
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

---

1. Introductions
2. Updates
3. CDR Stream updates
4. Presentation
5. Q&A
6. 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.

⭐ indicates change from last week.

Type	Topic	Update
Standards	Version 1.26.0	Published: 24th August 2023 Change log
Maintenance ⭐	Maintenance Iteration 16	Meeting #3 was held 24/08/2023, minutes available here. Email [email protected] to request an invitation
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	31st of July 2023	View in browser here
DSB Newsletter ⭐	25th of August 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	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 317 - ‘Buy Now, Pay Later’ Product and Account Detail	6 October 2023 Link to consultation
Consultation	Decision Proposal 320 - CX Standards - Non-Bank Lending	31 August 2023 Link to consultation
Consultation ⭐	Design Paper: Consumer Data Right Consent Review	6 October 2023 Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation
Workshop ⭐	Non-functional Requirements Management Check out Noting Paper 323 - NFR Workshops	Workshop Series
Stakeholder Forum ⭐	Consent Review Stakeholder Forum Treasury and Data Standards Body (DSB) invite you to participate in the Consumer Data Right (CDR) Consent Review design paper stakeholder forum held virtually on Wednesday 6 September 2023, between 11am – 12pm AEST.	Email: [email protected] and we'll forward the invitation and dial-in details

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	Technical Standards - Register	James

None this week.

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.

Ticket #	Question	Answer
2046	I did go through the documentation but still have some doubts around use of mutual TLS. Can you please confirm how the exchange of certificates required to establish mutual TLS would occur between a DH and ADR?	The actual process for MTLS is dictated by the normative standard referred to at: https://tools.ietf.org/html/rfc8705 We have published a sequence diagram showing how this fits into the overall consent authorisation flow at: https://cdr-support.zendesk.com/hc/en-us/articles/5300325565199-Consent-sequence-diagrams In summary, however, and without wanting to proscribe how you interpret and implement the standards to specifically, basically a Data Holder will: - Use HTTPS for the MTLS bound endpoints with a server certificate provided by the CDR CA - Verify that any call to this endpoint is bound to a client certificate also provided by the CDR CA - When issuing access tokens ensure that they are bound to the thumbprint of the client certificate presented by the ADR - When verifying an access token for an API call check that it is bound to the thumbnail of the presented client certificate
2071	based on my previous question on Get Metrics v4, looks like we can't omit the number for previousMonths. Get Metrics v4 is introducing some new measures. Just want to confirm we can return 0 for previousDays and previousMonth on the 1st day of implementation	This is only relevant for the historic arrays (ie. previousDays, previousMonths). The description in these arrays is that the first element is the last period (yesterday or last month) and so on backwards. This is deliberate as any data holder going live will have no historic data. If you only starting collecting the data from a specific day/month then only include elements in the array up that boundary. For instance, if you went live two days ago the the currentDay can be shown and two elements should be present in 'previousDays'.
2071 Part 2	Just to clarify, on day 1 of ACCC calling our new Get Metrics v4, we would show something like the following. I’ve highlighted the blank arrays below. Is this correct ? { "data": { "requestTime": "2023-08-18T05:00:00.000Z", "availability": { "aggregate": { "currentMonth": "1", "previousMonths": [] }, "performance": { "aggregate": { "currentDay": "1", "previousDays": [] },	That would be correct if there is no data. I would expect you to have data for the aggregate value, however, as the aggregate value is included to capture the data that was previously being reported in v3. For instance, if a data holder had been operating for two and half months and the ACCC called v3 they would give this response for v3 availability: { "data": { ... "availability": { "currentMonth": 1, "previousMonths": [ 1, 1 ] }, ... } } If the ACCC called v4 on the same day but the Data Holder had only just started supporting v4 then the availablity section would be: { "data": { ... "availability": { "aggregate": { "currentMonth": "1.0, "previousMonths": [ "1.0", "1.0" ] }, "unauthenticated": { "currentMonth": "1.0", "previousMonths": [] }, "authenticated": { "currentMonth": "1.0", "previousMonths": [] } }, ... } }
2072	clarification regarding NFR V4 & V5. Just to reconfirm, does consent amendment flow abandonments should be considered for consent abandonment metric? And on a edge case scenario, if a consumer is going through a consent authorization flow at the time of CDR metrics call is being invoked, that particular flow could be counted as a abandonment flow, which could be successful flow. That would be acceptable?	Q: Clarification regarding NFR V4 & V5. Just to reconfirm, does consent amendment flow abandonments should be considered for consent abandonment metric? A: I"m sorry. I don't understand this question. Could you expand on what you're seekign to confirm? Q: Clarification regarding NFR V4 & V5. Just to reconfirm, does consent amendment flow abandonments should be considered for consent abandonment metric? A: I"m sorry. I don't understand this question. Could you expand on what you're seekign to confirm? Q: And on a edge case scenario, if a consumer is going through a consent authorization flow at the time of CDR metrics call is being invoked, that particular flow could be counted as a abandonment flow, which could be successful flow. That would be acceptable? A: That doesn't sound acceptable. It would be a false positive in the metrics. Q: And on a edge case scenario, if a consumer is going through a consent authorization flow at the time of CDR metrics call is being invoked, that particular flow could be counted as a abandonment flow, which could be successful flow. That would be acceptable? A: That doesn't sound acceptable. It would be a false positive in the metrics.
2072 Part 2	As for the 1st question, in order to do a consent amendment, the end user goes through a consent amendment user journey (similar to consent authorization). And in technical terms consent amendment is to be treated as a new consent authorization by revoking the previous consent. In that note consent amendment could be considered as a consent authorization flow as well. Hence do the data holders have to consider abandonments in consent amendment flow for the consent abandonment metric?	In response to your query, yes an amendment flow should be reported on in Get Metrics just as an initial authorisation flow would be.
2080	For the GetMetrics API is has metrics divided between Unauthenticated and Authenticated APIs. For DCR and Infosec APIs, should we consider these authenticated or unauthenticated?	The endpoints that are considered unauthenticated the PRD, status and outage APIs. These are genuinely unauthenticated in that even the client is not known or authenticated. DCR and InfoSec endpoints may be publicly available but they are still client authenticated and considered to be part of the authenticated side of the CDR implementation.
2082	This query is regards to transactions APIs, and their maximum page size. The Standards states that a maximum page size of 1000 can be set for endpoints that return multiple records. Is there flexibility to reduce this maximum to a smaller value? Our systems are only able to support 500 transactions to be returned one on page, so we would prefer to limit our page size to 500 maximum. Additional transactions could of course be included in additional pages. Other open banking regulations allow a maximum page size of just 100, so we feel that this should still be more than enough for consumers. Alternatively, if someone were to request a page size of between 500 and 1000, would it be acceptable if a response only had 500 records on each page (with the additional records appearing on subsequent pages)?	I'm afraid that the standards are clear on this point. A client is able to request 1000 transactions per page for banking transactions and the data holder is expected to respond with 1000 transactions if requested.
2083	The data standards currently state that a "sub" claim must be supported for the end user at the data holder, that it must be passed in the ID token and the user info response and that "sub" is a pairwise psuedo-anonymous identifier as per s8 of OIDC. Is it expected that this value should be preserved across consents for the same end user for the same client (i.e. a fixed sector_identifier_uri) value? This appears to not be the case for some providers and wanted to confirm.	Yes, the sub claim is expected to remain consistent across multiple consents for the same combination of customer, data recipient and data holder. Note that the definitions in the CDR Federation section of the standards apply here. This means: - Customer is defined as customer profile as determined by the data holder. A single customer (as defined by the data recipient) may have access to multiple customer profiles resulting in different subs for each data holder defined profile (ie. I would have a different sub sharing my personal accounts and my business accounts) - Data recipient is defined as software product and not legal entity. This means that there would be different subs for different software products from the same ADR - Data holder is defined as data holder brand and not legal entity. This means that there would be different subs for different master brands of a single bank (ie. UBank vs NAB)
2085	This is a question from our engineers. They are looking at the POST /register API endpoint, and did not see an example of a decoded JWT of the ClientRegistrationRequest that is used in this endpoint. Is it possible to provide an example?	If you search on the Standards page for 'Registration Request using JWT', there should be only one instance and there is an example on the right (pic attached). The DCR JWT includes the "software_statement" property which is another JWT, which described just above that section in Software Statement Assertion (SSA).
2085 Part 2	We did have a separate question related to DCR. Is there a QA URL that we can use for the CDR Register, as we begin to start testing calls that we make to the register, specifically the Get JWKS call? Our security team requires that we use QA links in our QA environments.	There are no specific QA URLs for the Register that I can provide, but you may find the information available on the For providers page helpful during development, in particular the Participant tooling section.
2087	In relation to GetMetrics Schema for v4 and v5, the newly introduced “Authorisation Metrics” object is denoted as an optional field. Is this intentional ? Ref. to standards: https://consumerdatastandardsaustralia.github.io/standards/#tocSrequestmetadataupdate Properties: » authorisations AuthorisationMetricsV2 optional Authorisation counts for the data holder We note that “OPTIONAL” is typically taken to mean that if the data is held by the DH, then the optional field becomes mandatory. Given that the ecosystem is driven by explicit consent authorisations, is this effectively a “MANDATORY” object for all data holders? An alternative interpretation is that DSB intends for DataHolders not to return anything at all at this level, if all of the mandatory sub-objects under AuthorisationMetrics are not available on a particular day (eg operational issues).	That is not intentional. The issue has been noted in the Maintenance Iteration 16 Holistic Feedback issue and may be expected to be corrected to 'mandatory' in the next version of the Standards.

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.