Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 26th of August 2021

Jump to bottom
CDR API Stream edited this page Aug 26, 2021 · 3 revisions

ACCC & DSB | CDR Implementation Call 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: 1650705270@webex.com

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 contact@consumerdatastandards.gov.au 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.11.0 Published Link to change log here
Standards Version 1.11.1 Drafted Standard-staging Version 1.11.1
Change log for Version 1.11.1
Maintenance 8th Maintenance Iteration Commenced Agenda from the 11th of August 2021 meet
Maintenance Decision Proposal 202 - Banking Maintenance Iteration 8 Link to consultation
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 18th of August 2021 View in browser here
DSB Newsletter 20th of August 2021 View in browser here
Consultation Decision Proposal 180 - Energy Draft Feedback Cycle 3 Link to consultation
Consultation Decision Proposal 193 - Energy Non-functional Requirements Link to consultation
Consultation Decision Proposal 194 - Candidate NMI Standing Data End Points Link to consultation
Consultation Decision Proposal 200 - Action Initiation Framework Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 206 - Register Standards Link to consultation
Consultation Decision Proposal 207 - Draft v3 Rules Analysis - Anticipated Data Standards Link to consultation
Consultation Decision Proposal 208 - Binding NFRs Link to consultation
Event Introduction to the Consumer Data Right Link to register
Community New! Community Pulse Check Survey from Quill Peak.
It requires completing just six (6) questions and will take no more than 5 minutes to complete.
All responses are confidential, and we will not publish information that could identify an organisation or an individual participant such as your name, email address or company particulars.
Everyone who responds will be sent a copy of our report.		 Link to the CDR Community Forum and Pulse Check Survey here

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation Stream Member
ACCC CDR Register (Technical) Ivan Hosgood
ACCC CTS Andrea Gibney
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None this week.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

Ticket # Question Answer
979 In the one of the article it stated "The isDetailAvailable field should be set to false for Get Transactions API calls if the Data Holder does not support the NPP data." That means the Get Transaction Details API is meant for only NPP payment?
In Transaction details we have following details.
Entire transaction block
Extended Data block (i.e payer, payee, extensionUType, x2p101Payload, extendedDescription, endToEndid, purposeCode, service)
It looks we no need to populate extended Data block for non-NPP payments, but what about Entire transaction block?		 That's correct. Currently the data standards only support transaction detail for the NPP X2P1 service overlay (Osko). This will be expanded in future as new service overlays are adopted or transaction detail is available for other payment schemes.
984 Do we need to respond with page-size, in the following scenarios;
1. In the ADR request, if we receive only 'Page' without 'page-size': In the response records more than default page size (default 25 records) then in the "Self" link do we need to add page & page-size?
2. in the request if we receive Page and Page-size then in the response "Self" links do we need to add Page & Page-size?		 Question 1. In the ADR request, if we receive only 'Page' without 'page-size': In the response records more than default page size (default 25 records) then in the "Self" link do we need to add page & page-size?
Answer 1: Yes. If you have more results than were returned in the response you must provide the page and page-size in the link references.
Question 2. In the request if we receive Page and Page-size then in the response "Self" links do we need to add Page & Page-size?
Answer 2: Yes. This would be the fully qualified URI to the response provided. Similarly, page and page-size are required to describe the first, last, previous and next links
988 With our implementation, we are able to throttle out the 21st unattended session as expected. Also, this will prevent access to the 20th or earlier sessions, even if they are still in the active status. Bearing in mind the sessions are short lived and ADRs will not get a new access token while there's an active token available, we hope this behaviour is accepted. I believe this aligns with standard usage of OIDC tokens and with the CDR standards.
992 Could you please clarify if the data holders who support the CDR Arrangement Revocation End Point still have to support the token revocation endpoint mentioned at https://consumerdatastandardsaustralia.github.io/standards/#end-points
Some parts of the published standards and CTS mention it as mandatory: The standard in it's current version 1.11.0 states that 'Data Holders MUST implement a Token Revocation End Point as described in section 2 of [RFC7009]' and Scenario 10 in the CTS cover token revocation DR to DH.
However other parts mention it as not mandatory: another paragraph of the standards says 'If the Data Holder does support the CDR Arrangement Revocation End Point, Data Recipients MUST use the Data Holder's CDR Arrangement Revocation End Point with a valid cdr_arrangement_id to notify the Data Holder'. The standards version 1.9 state that 'Data holders may obsolete consent revocation via this end point from February 1st 2021, however they must still support oAuth token revocation. This article also seems to indicate that the data holders do not need to publish a token revocation endpoint https://cdr-support.zendesk.com/hc/en-us/articles/900001579626-Revocation-Endpoint.
So what do data holders MUST do? And what does it mean that data holders must still support oAuth token revocation? Via the arrangement ID revocation endpoint?
If the data holders still have to expose the token revocation endpoint what is the use case for it? If the data holders do not have to expose the token revocation endpoint anymore since by now they have to expose the arrangement revocation endpoint, why is the token revocation endpoint still mentioned as a must in the standards? Should it not be deprecated an taken out of the standards by now?
In a similar fashion, do data holders have to support calling the Token revocation endpoint exposed by ADRs? Or is it enough if the data holders call the ADR exposed CDR Arrangement Revocation End Point since by now all the ADRs should have implemented one. If this is the case, why is the token revocation endpoint still mentioned for Data recipients? Should it not be deprecated by now and taken out of the standards?		 Data Holders must support oAuth Token revocation (token revocation endpoint). The data standards made a change to separate withdrawal of consent from the management of tokens. To withdraw consent, ADRs are now required to call the Data Holder's CDR Arrangement Revocation Endpoint.
With this change, the ADR token revocation endpoint was retired and replaced with the CDR Arrangement Revocation endpoint. Data Holders seeking to notify ADRs of consent withdrawal must do so via the ADR's CDR Arrangement Revocation Endpoint. ADRs no longer need to provide a token revocation endpoint.
You have picked up on a documentation bug. That section you reference regarding the ADR Token Revocation endpoint has been left for historical reference but must be removed now that it is no longer required. I'll create a change request to identify the issue and resolution.
995 We have situation where a brand has two identities within it - eg two different logins within a brand that provide online access to different products. We have a plan to bring these two logins into a single "brand" login, however, as an interim was to propose to allow the customer to create different shares with recipients using the two identities within the brand. For example through a Recipient the customer would select the brand twice and enter different identities for each consent flow. Is this an allowed / supported approach within the rules, eco-system and for recipients. I believe these scenarios were covered in the white labelling guidance at https://cdr-support.zendesk.com/hc/en-us/articles/900003938166-White-Labelled-brands-in-the-CDR.
The TLDR; is that this would be acceptable if it is what the customer would expect to occur and it wouldn't be confusing for them. The other alternative that is entirely acceptable under the rules is to have a single brand but ask the customer, during the authentication phase of consent, which identity type they would like to authenticate with.
In either solution they could create a separate consent for each identity if they so desired.
1002 There are 3 fields under CommonPafAddress schema that refer to an enumeration defined by the Australia Post PAF Code File:
streetType- The street type. Valid enumeration defined by Australia Post PAF code file
streetSuffix-The street type suffix. Valid enumeration defined by Australia Post PAF code file
postalDeliveryType -Postal delivery type. (eg. PO BOX). Valid enumeration defined by Australia Post PAF code file
1. Can you confirm if the PAF code file is https://auspost.com.au/content/dam/auspost_corp/media/documents/australia-post-data-guide.pdf
2. For these values, is the Full name or the Abbreviated value expected or are both forms valid
See page 37 for list of street type codes
For Example for a street address that contains Court or Parade
are both "Court" and "CT" considered valid response values for StreetType ?
"Court" or "CT" or
"Parade" or "PDE"		 the street type is intended to be the enumerated code (e.g. "CT"), not the display name (e.g. "Court").
1004 The nominated linked account is an everyday transaction account that the customer holds with another Australian financial institution. Sometimes it can also be an internal account owned by another entity.
The nominated account is used to transfer money in and out of the customer’s savings account. Generally nominated linked accounts need to be in the same name and entity type as account.
This type of savings product doesn’t allow customers to make third party payments to anyone else except to their nominated accounts. These nominated accounts are visible in Internet Banking however it comes under the account transfer category and not in the payees address book.
We would like to seek clarification if we need to classify nominated accounts as payees for the purpose of Open Banking ?		 The answer to this question is entirely in the determination of you as the data holder. Clearly this is being used to support payments as a registered payment target but payees are not account aligned and these nominated accounts are.
I would suggest a better resolution would be to raise a change request for us to add nominated accounts to the account details end point as an optional structure in the same way we currently support offset accounts.
1010 In the DD we have 3 endpoints, do we need to consider optional fields while providing response?
i.e lastDebitDateTime & lastDebitAmount because these data needs to capture from Transaction store.		 yes you do. If you have the data or can infer the data from the transactions then it needs to be provided. It is optional for the purposes that the two values may not be inferred for all direct debits.
1012 We have products that have tiered rates on transaction accounting products. These do not fall under either a Term Deposit or a Lending product. How do we represent the tiered rates or rates for transaction accounts/savings account? The depositRates structure can be applied to any product and is not exclusively reserved for term deposit accounts. You would be expected to use this structure in this case.
1014 - The "Private Key JWT Client Authentication" section of CDS spec [1], states that the Authorisation Servers MUST support the authentication of clients using the private_key_jwt Client Authentication method specified at section 9 of [OIDC].
- In the section 9 of [OIDC] [2], no any specific validations are stated about the client_id sent in the request. In addition, referring to the OAuth JWT Assertion Profiles [3], the client_id is not listed as a mandatory request parameter during a private key jwt authentication scenario. Both these specifications discuss about sending the client_id as the "subject" claim value of the client-assertion.
- But in the "Private Key JWT Client Authentication" section of CDS spec [1], "client_id" is listed as a REQUIRED parameter in a request sent to Authorisation Server's Token endpoint.
Hence, this inclusion of "client_id" in the request is a rule imposed by the CDS specification. But that section specifically states that it is for Authorisation Server's Token endpoint. Therefore, we expect clarifications on following two queries.
1. What is the CDS guideline on validating the "client_id" parameter sent in a token request?
Should that be validated against the "subject" claim value in the client-assertion and rejected if the "client_id" in the request is different to the "subject" claim in the client-assertion ?
2. The same "Private Key JWT Client Authentication" section applies as a guideline when enforcing client authentication for other endpoints such a Push Authorization, CDR Arrangement Revocation and etc.
Does the CDS mandate the "client_id" as a REQUIRED parameter for those requests as well?
[1] https://consumerdatastandardsaustralia.github.io/standards/#client-authentication
[2] https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
[3] https://datatracker.ietf.org/doc/html/rfc7523#section-2.2 		Section 9 of OIDC pertains to the JWT signed by the client and presented as the client assertion. The client_id is sent to identify the confidential client identify when sending requests to the token endpoint as part of authenticating its client credentials (grant_type=client_credentials) - see section 3.2.1 of RFC6749: https://datatracker.ietf.org/doc/html/rfc6749#section-3.2.1. The client_id is required for requests utilising mutual-TLS client authentication (https://datatracker.ietf.org/doc/html/rfc8705#section-2).
Question 1a. What is the CDS guideline on validating the "client_id" parameter sent in a token request?
Answer: The client_id is the value the DH issues to the confidential client (ADR software product) as part of Dynamic Client Registration. The subject in this instance is the confidential client.
Question 1b: Should that be validated against the "subject" claim value in the client-assertion and rejected if the "client_id" in the request is different to the "subject" claim in the client-assertion ?
Answer: Yes
Question 2. Does the CDS mandate the "client_id" as a REQUIRED parameter for those requests as well?
Answer: The requirements for passing and validating the client_id or other required parameters defined in the Private Key JWT client authentication section applies to any endpoints that require Private Key JWT client authentication
1019 The CDS Availability Requirements NFR provides the below statement –
“The definition of a period of unavailability is any period of time when any of the API end points defined in the standard is unable to reliably provide a successful response to an appropriately constructed request.”
https://consumerdatastandardsaustralia.github.io/standards/#availability-requirements
Could you please provide any further clarification or guidance on whether it would be necessary to consider data latency in determining whether an API end point is providing a ‘successful response’?
Data latency in the above context means a difference between the values returned in a CDR API response and what our source systems may hold for the equivalent data at that point in time.
As an example for context; if our API was ‘reliably’ responding to requests, but returning cached data from 2 hours ago, would that be considered as ‘available’ and ‘successfully responding’ in these two cases –
- Other primary digital channels also reflected the same delay (i.e. the API response is the same as other channels)
- Other primary channels did not have the same delay (i.e. the API response is delayed compared to other channels)		 This is an interesting question and hasn't come up before.
I would say that this situation would not be considered unavailability but it would still be in breach of the data latency requirements in the NFR and should not be considered a successful outcome.

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