-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (24th of June 2021)
When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:
Desktop or Mobile Devices
https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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: 785383900@csiro.webex.com
Phones - AUDIO ONLY
- Primary Australia: +61 2 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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.
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.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.10.0 Published | Link to change log here |
| Standards | Version 1.11.0 Draft Board | Link to Version Project Board here |
| Maintenance | 7th Maintenance Iteration underway | Agenda of the backlog session |
| Maintenance | Decision Proposal 178 - Banking Maintenance Iteration 7 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| TSY Newsletter | 24th of June 2021 Edition | View in browser here |
| DSB Newsletter | 18th of June 2021 Edition | View in browser here |
| Consultation | Decision Proposal 180 - Energy Draft Feedback Cycle 3 | Link to consultation |
| Consultation | Decision Proposal 182 - InfoSec Uplift for Write | Link to consultation |
| Consultation | Decision Proposal 183 - Purpose Based Consents | Link to consultation |
| Consultation | Decision Proposal 186 - Engineering Support | Link to consultation |
| Consultation | Decision Proposal 187 - CX Standards - Disclosure Consents | Link to consultation |
| Tooling | Java Artefacts Version 1.10.0 has been published | Link to artefacts |
| Action | Will the ACCC require data holders to retest via CTS for CDR2? should we prepare for this? |
As per the current published Participant Test Strategy under certain circumstances, the ACCC may mandate or request that existing/active Participants retest their solution in the CTS. This may include a subset or all of the CTS tests in a test plan. While the CTS roadmap for November is currently in development, it is expected that Participants are prepared to undertake CTS testing when requested. In order to retest conformance, a participant must have a set of endpoints different to their production endpoints, with which the CTS can interact. Those endpoints must be configured to use a CTS certificate. No real consumer data must be communicated or used when interacting with the CTS via these endpoints, as the consumer will not be able to provide consent to the CTS. As per the Consumer Data Sharing obligations, Participants will be required to continue sharing consumer data via their production solution while CTS testing is being executed. |
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 | Onboarding | Jonathon Ingle |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
None this week.
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
| Ticket # | Question | Answer |
|---|---|---|
| 826 - Part 2 | but it leads few other question. "isDetailAvailable" field is available in 'Get Transactions For Account' & 'Get Transaction Detail' endpoints but the "extensionUType" is available only for Get Transaction Detail. 1. In case of 'Get Transactions For Account' endpoint what value will go for "isDetailAvailable"? - If transaction type is NPP then assign as True else False? 2. In case of 'Get Transaction Detail' endpoint what value will go for "isDetailAvailable"? - If transaction type is NPP then assign as True else False then don't return the entire 'extendedData' block.. is it? |
Question 1: In case of 'Get Transactions For Account' endpoint what value will go for "isDetailAvailable"? - If transaction type is NPP then assign as True else False? Answer: This field is used where there is detailed transaction data available for the NPP payment. Question 2: In case of 'Get Transaction Detail' endpoint what value will go for "isDetailAvailable"? - If transaction type is NPP then assign as True else False then don't return the entire 'extendedData' block.. is it? Answer: A transaction can only validly have extended data if it was executed using the X2P01.01 overlay service. Other transactions should give false in the isDetailAvailable field and should give a 404 if extended data is requested. |
| 835 - Part 2 | The fact that you are pointing out is correct. The concern for us is although the above threshold is related to sessions, this is applicable only for unattended traffic according to the spec. But when issuing access tokens, we cannot limit the token to unattended or attended traffic. Therefore the only possible way we see here is limiting the session count of unattended API invocations. Are we on the right track understanding this policy? |
The intent of these statements was that a session that only does attended traffic would be an attended session and a session that does any unattended traffic would be considered unattended. Bearing in mind that sessions are short lived the reality is that there is unlikely to be mixed traffic types for a single session. This means that for the 21st session that makes unattended traffic calls a data holder can reject the invocations under the NFRs of they choose to. |
| 862 - Part 2 | On the phasing question. If the request is for an unsupported API, eg: get customer details before Nov21, it's clear we'll respond with a 404. How about if it's for in scope and out of scope data. For example a request for a get bulk direct debits post Nov21 for active accounts and a close account? It's still a 404 response even if we could respond with direct debits details for the active accounts? |
This should already be accommodated. Direct debits can only be requested for valid account IDs and the ADR would not have received a valid account ID for an out of scope account. If a valid account changes status or is detached from the consent then the account ID is also no longer valid. In both instances it would be a 422 with the appropriate error URN for the specific circumstance. |
| 867 | As described in article (https://cdr-support.zendesk.com/hc/en-us/articles/360004722076-Reporting-Exemptions), if a request is a incorrect API request, they need to be considered for reporting and for calculation of different metrics. But need to clarify the following. Some example incorrect API calls: POST /token2 (wrong resource path in a infoSec call) - 404 status code GET /cds-au/v2 (non-existant base path in a resource call) - 404 status code GET cds-au/v1/banking/accountsz (non-existant resource path) - 404 status code PUT cds-au/v1/banking/accounts (wrong method invoked) -405 status code 1. As of my understanding, non of above requests falls into any performance tiers as these calls are for non-existent endpoints. Therefore, these incorrect API calls doesn't need to be included for PerformanceMetrics, InvocationMetrics and AverageResponseMetrics calculations. Can you confirm whether this understanding is correct? 2. For averageTps and PeakTPSMetrics, the Transactions per second over time is considered. Therefore, should the above incorrect API calls be considered as separate transactions and considered for averageTps and PeakTPSMetrics calculation? 3. If there is any CDS defined explanation for a accepted API call and a transaction, please provide those as well. |
the examples you provided present endpoints that are not part of the Consumer Data Standards. They would not be considered part of metrics reporting. With the examples you provided, there is no non-disclosure of CDR data because the APIs in your example are not defined by the standards. |
| 868 | While implementing Get Transactions For Account services, we have found that for some of transactions, reference field is absent. As per CDS page it is a mandatory field but can be an empty string if not present. Wanted to understand what is the intent of this field ? If intend is to categories transaction type, can DH holder pass Transaction code instead e.g. 851 Laon Repayment. But this code will not uniquely identity Transaction like in description field Ref# character. Can you provide guidance on this? | You are correct, the reference field is mandatory and is required to be supplied by Data Holders. The intent of the field is provided in the description. It is not intended to pass a categorisation code inferred by the data holder unless that is the reference provided by the originating institution. |
| 877 | Admin APIs and Product Data - Understand that there have been some previous questions on this, but answers have still left some ambiguity. Specifically would like to understand whether the Admin APIs must provide information around product data requests (eg GetMetrics), and, whether this is mandatory. Can you point us to where this is described in the rules or standards, or is it more implied from the unauthenticated requests item in GetMetrics? |
the Product Reference Data (PRD) endpoints are defined to be within the Unauthenticated tier. The Get Status and Get Outages public, unauthenticated endpoints, are defined within the High Priority tier. https://consumerdatastandardsaustralia.github.io/standards/index.html#performance-requirements Metrics must be collected and reported on for PRD endpoints. |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |