Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14th of October 2021

Jump to bottom
CDR API Stream edited this page Oct 14, 2021 · 4 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT
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: [email protected]

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 [email protected] 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.1 Published Link to change log here
Standards v1.12.0 is now in Standards-Staging V1.12.0 scope: Consumer Data Standards V1.12.0 Project Board
Maintenance 9th Maintenance Iteration Agenda from the 6th of October 2021 meet
Maintenance Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 9th Maintenance Iteration Meeting Details Now included on Decision Proposal here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 7th of October 2021 View in browser here
Consultation Decision Proposal 197 - Candidate Account End Points Link to consultation
Consultation Decision Proposal 198 - Candidate Billing & Invoicing End Points Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 213 - CX Standards & Energy Data Language Link to consultation

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 Matt Orrell
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

Title: Participant Tooling from the ACCC
Presenters: Andrew Grady and Tom Davies
Links:

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
1102 Based on our understanding of the information in the CDR Data Standards, for a recurring Scheduled Payment that is to be paid on the last day of the month in the interval, the ‘dayInInterval’ field in the BankingScheduledPaymentInterval schema should be populated with a value that is equal to or greater than the last day of the interval (e.g. for a Monthly recurring payment to be paid on the last day of the month the ‘dayInInterval’ value should be ‘P31D’).
For scenarios with intervals greater than one month (e.g. payment to be made every 2 months, or every 6 months, on the last day of the month), is it correct to follow the same pattern and populate the ‘dayInInterval’ field with a value equal to/greater than the last day of the interval (e.g. ‘P62D’ for 2 monthly interval recurrence and ‘P184D’ for 6 monthly interval recurrence)?		 The interpretation is correct. The examples you gave for 2mo or 6mo would be appropriate. However, you could also use P0D because this is defined to mean the last day in the interval. This may be preferable because it doesn't matter what your recurring interval period is, P0D will always indicate the last day.
Here is the relevant snipped of the dayInInterval description in the data standards:
If the resulting duration is 0 days in length or larger than the number of days in the interval then the payment will occur on the last day of the interval.
Similarly, ISO8601 permits negative durations. P-1D would indicate 2 months minus one day, or 6 months minus one day. This is convenient as shorthand duration for a day in the interval towards the end of a recurring interval.
1103 What response should a Data Holder respond with for Get Transactions for Account if the oldest-time set by the Data Recipient is set in the future? Would a 400 Bad Request be appropriate or a 200 OK with an empty array should be sent back?
Also, what if the oldest date is before 1 January 2017 or more than 7 years in the past (not relevant just yet) and the newest-time is after 1 January 2017 or less than 7 years from request date?. Should the Data Holder respond with transactions between 1 Jan 2017 - newest-time OR 7 years ago -newest-time? Or should the request be errors with 400 Bad request?
And a lost scenario, if bothe the oldest-date and newest-date are before 1 Jan 2017 or more than 7 years ago? Should the DH respond with a Bad Request error or empty array?		 [Question] What response should a Data Holder respond with for Get Transactions for Account if the oldest-time set by the Data Recipient is set in the future? Would a 400 Bad Request be appropriate or a 200 OK with an empty array should be sent back?
[Answer] In this instance, if the oldest-time is known to be outside a supported range (say 10 days into the future) or an impossible date (i.e. oldest-date is newer than newest-date) then a 400 Bad Request with error code "urn:au-cds:error:cds-all:Field/InvalidDateTime" applies.
[Question] Also, what if the oldest date is before 1 January 2017 or more than 7 years in the past (not relevant just yet) and the newest-time is after 1 January 2017 or less than 7 years from request date?. Should the Data Holder respond with transactions between 1 Jan 2017 - newest-time OR 7 years ago -newest-time? Or should the request be errors with 400 Bad request?
[Answer] Same as above
[Question] And a lost scenario, if bothe the oldest-date and newest-date are before 1 Jan 2017 or more than 7 years ago? Should the DH respond with a Bad Request error or empty array?
[Answer] Same as above
If the dates provided are within the valid range however there are no records available an empty set with 200 OK response would be correct.
1104 The data standards for currentBalance has this description: "The balance of the account at this time. Should align to the balance available via other channels such as Internet Banking. Assumed to be negative if the customer has money owing".
Does this mean that for loan accounts, the Data Holder should include a minus sign (-) in the currentBalance field if there is an amount owing?		 Yes, for a loan with an outstanding balance the value should be negative. This would apply to any account that can have a negative balance. For example, mortgages, credit cards or transaction accounts with overdraft facility can all return a negative balance.
1120 As per the Consumer Data Standard "Data Holders MUST indicate where a dataset is being added to an authorisation or a disclosure duration is being amended. Data Holders MAY apply this standard to other changing attributes, but this MUST ONLY apply where the attribute in the new authorisation differs to that of the previous authorisation. How a changed attributed is signified is at the Data Holder’s discretion."
If the duration of the existing consent is amended, then it is an obligation of a DH to show what has changed from previous consent to that of new consent? for eg. previous consent was for 12months and consent duration is amended and extended for another 6months. DH should show what has changed i.e. previous consent data sharing period was for 12months from Jan'21 to Dec'21 and new consent sharing period is for another 6 months from Jan'22 to July'22? OR only the data sharing period of the new consent with the label as "New" as shown in CX guidelines is enough.		 As per the standards statements you have quoted "How a changed attributed is signified is at the Data Holder’s discretion."
This means it is at the discretion of the data holder how the change is shown, explained and emphasised.
1122 As per the standards the following cipher suites need to be supported:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Our implementation is unable to support the following two ciphers as they are deemed insecure:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Can you please comment in whether we can only support the following ciphers:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384		 The wording of the requirement in the upstream specification is that only those four ciphers SHALL be permitted. The Data Holder has discretion to choose which of those ciphers they support.
1123 seeking clarification of how the DH determines/verifies the client_id in the PAR request.
Article https://cdr-support.zendesk.com/hc/en-us/articles/4405800416143-Client-authentication-and-client-id mentions that the client_id parameter is validated against the "sub" claim in the client assertion.
However; the CDR specification does not include client_id as a parameter nor a sub claim. Only client_id is presented as a claim.
Is it correct to infer that the client_id is obtained directly from the client_assertion?		 The client_id is required in the request syntax and the request object passed to the PAR and/or authorize endpoint. This is required by oAuth 2.0 and is covered in OIDC section 6.1. The client_id is not in the client_assertion itself but in the request syntax and request object JWT
So that the request is a valid OAuth 2.0 Authorization Request, values for the response_type and client_id parameters MUST be included using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for these parameters MUST match those in the Request Object, if present.
1124 According to the CDS specification[1], it states to send the x-fapi-financial-id for the 4XX errors.
"An RFC4122 UUID used as a correlation id. If provided, the data holder must play back this value in the x-fapi-interaction-id response header. If not provided a [RFC4122] UUID value is required to be provided in the response header to track the interaction."
According to the RFC specification[2],
"The 501 (Not Implemented) status code - indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource."
Therefore in a scenario where the server is supporting only the main HTTP methods(GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE) as in [3], it should be correct to send the 501 response for methods non-supported by the server and send the 405 response along with the x-fapi-financial-id only for the supported HTTP methods.
Let us know your feedback on this.
[1] - https://consumerdatastandardsaustralia.github.io/standards/#get-accounts
[2] - https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.2
[3] - https://datatracker.ietf.org/doc/html/rfc7231#section-4.1 		there is no question in the submitted issue, however if I can paraphrase what I understand the problem to be. You are asking if the x-fapi-interaction-id should be a response header in the event of 5xx errors?
x-fapi-interaction-id must be responded to for 4xx errors on protected resource endpoints. The CDS is not prescriptive for 5xx because this often involves server issues or default configuration of error responses that never reach API gateways or application code.
The x-fapi-interaction-id should be treated as a SHOULD in 5xx cases as recommended if possible to do so.

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