ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (21st of January 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (21st of January 2021)
When: Weekly every Thursday at 3pm-4.30pm AEDT
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: [email protected]
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
Agenda
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- 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.6.0 Published | Link to change log here |
| Standards | Version 1.7.0 Proposed | Link to Project Board with proposed changes here |
| Maintenance | 6th Maintenance Iteration planned for 2021 | Invitations sent yesterday - if you did not receive or would like to join these please reach out to [email protected] |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 20th of January 2021 Edition | View in browser here |
| DSB Newsletter | 15th of January 2021 Edition | View in browser here |
| Consultations | Decision Proposal 149 - Energy Draft Feedback Cycle 1 Feedback is now open on any issue related to draft. This thread will remain open until February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence. | Link to consultation |
| Consultations | Decision Proposal 145 - Strategy for Reporting & Metrics Feedback is now open for this proposal for an extended period to account for the end of year break. Feedback is planned to be closed on Friday 25th January 2021. | Link to consultation |
| Consultations | Decision Proposal 144 - Amending Consent Authorisation Flow Feedback is now open for this proposal for an extended period to account for the end of year break. This consultation window will close on ( extended to ) Monday, 1st February at 5pm. | Link to consultation |
| Service Provider Directory | Request from the community; organisations are seeking independent tester(s) to carry out system testing prior to entering the CTS | ACTION: Please submit your details to [email protected] and we will add these to the Service Provider Directory for participants to review Please provide your: Name of your organisation Logo of your organisation What service(s) you provide URL to your website Description of your organisation |
| CDR Support Portal | Clarification on aud claim for a Data Recipient hosted arrangement revocation endpoint | CDR Support Portal Article |
CDR Stream Updates
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Rules | Andrew Breeze |
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
Presentation
An overview of the new CX Guideline platform, structure, and CX assets presented by Michael Palmyre from the Data Standards Body.
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.
Current received pre-submitted questions:
Answer provided
| Ticket # | Question | Answer |
|---|---|---|
| 379 | The following section outlines a data holder's responsibility on sharing data based on the ADR and SP status held by ACCC - https://cdr-register.github.io/register/#data-holder-responsibilities Can we please check whether there are any guidelines for Data Holders to manage this internally? (e.g. if we discovered that an ADR was involved in a fraud incident - and would like to stop sharing customer data with them - but the ADR and SP status at ACCC continue being active). | The issues you raise are addressed in the Rules which has been explained in an FAQ on Blacklisting ADRs. |
| 386 | 1. Will the register support ES256 and sign the SSA using ES256 instead of PS256 if our preferred algorithm is (we will be nominating ES256 via our OIDC endpoints) 2. Is it required for DH to support both ES256 AND PS256 ? As per As per FAPI-RW - For JWS, both client and Auth servers can use PS256 OR ES256 (8.6 - https://openid.net/specs/openid-financial-api-part-2.html) | 1 Answer: No. The CDR Register will only be using PS256 to sign the SSA. There is no planned work to provide options on the SSA signing algorithm used. 2 Answer: The CDR Register has chosen to use PS256 as the signing algorithm, conforming to section 8.6. The result of this is that your registration server will need to be able to check the signature of the PS256 signed SSA. How you choose to sign your own JWTs is up to you as long as you conform to the CDS. CDR Support Portal Article |
| 404 | What is the process for seeking an exemption or extension for components of compliance. The major banks Rectification Schedule lists a number of items they have not yet delivered and they have agreed on dates to rectify. If there are items we do not think we will be able to deliver by the CDR timeline, or if we would like an exemption for a particular white labeled product, what should we be doing to proactively raise this and avoid any fines. e.g. a letter, a meeting? Also, who should we be working with on this and what information will be required? Is there a template or guide? What is the timeline for seeking an exemption? How far ahead of the due date should this be commenced? | We have published guidance on seeking an exemption to anything under the CDR rule, which is available at the following link: https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/cdr-guidance-for-applicants-seeking-exemption-under-section-56gd CDR Support Portal Article - Understanding Compliance Exemptions |
| 422 | Can I further clarify the CDR Error Code and title for each scenario w.r.t. Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling? | At the moment the DP120 has not been approved. We are publishing a new error codes catalogue this week under a new DP based on the feedback we have received. I hope to have standardised error codes approved into the data standards this quarter (Q1). |
| 429 | We would like to clarify regarding the Get Product Details version, currently supported as per the Consumer Data Standards. As per the standards, v1 and v2 are mentioned as obsolete for Get Product Detail, But as per the "Future Dated Obligations" section, the version v2 discontinuation/obsolete date is not mentioned clearly. Could you please confirm till when v2 can be supported(Please Note:Version 3 to be made available by end of February 2021) As per Future Dated Obligation: Get Product Detail V2 : Version 2 of this end point must be made available by affected data holders by the end of July 2020 Data holders may obsolete version 1 of this end point from August 29th 2020. Data recipients must upgrade their implementations to use version 2 by this time. | The deprecation of v2 has not yet been consulted on. This will be discussed in our upcoming maintenance iteration. I would expect that a date a couple of months after v3 will be inline with expectations, so April or May 2021. Until that time, v2 needs to be supported. CDR Support Portal Article - Get Product Details v2 deprecation |
| 430 | I hope you are ok with all of this in one request - it all relates to the same issue. We are assessing all documented changes and making sure we have them either in build or planned. We have had trouble understanding some (based on the info provided in the release notes). In 1.5.0 there is an item listed under Infosec profile - the item that refers to DP135. We request that this be broken down into the specific changes to standards - we are unsure exactly what changes are contained under this item (but it is not at the same level of detail as other entries where each specific change to standards is a line item). Also in 1.5.0 there are two items under API endpoints that we simply could not identify (could not find a change): one was listed as Update to CRN description, and the other as BankingBillerPayee update. Could you please specify what changed? | In response to your questions: Q: In 1.5.0 there is an item listed under Infosec profile - the item that refers to DP135. We request that this be broken down into the specific changes to standards - we are unsure exactly what changes are contained under this item (but it is not at the same level of detail as other entries where each specific change to standards is a line item). A: Lower down in the release notes (in the InfoSec section there is a link to the DP135 document outlining the specific changes. The link is: https://github.com/ConsumerDataStandardsAustralia/standards/files/5159401/Decision.135.-.November.2020.Consent.Obligations.pdf In this PDF refer to the section titled Changes to current standards Q: Also in 1.5.0 there are two items under API endpoints that we simply could not identify (could not find a change): one was listed as Update to CRN description, and the other as BankingBillerPayee update. Could you please specify what changed? A: The change to CRN description was to change the description of the crn field in the BankingBillerPayee object. To include instructions for masking if the CRN matches the format of a credit card number. The other change was to introduce a crnType field that was then removed in v1.5.1 of the standareds (which is why it doesn't appear). CDR Support Portal Article - Changes in standards v1.5.0 |
| 439 | Would like to clarify a question regarding transaction Detail APIs payload. Payload has “extendedData” that has NPP transactions related data field ( extensionUType, extendedDescription, endToEndId, purposeCode, service). What is expected behaviour for a data holder who is not supporting NPP x2p101Payload and can only cater to “payer” & “payee” fields under “extendedData “? Shall Data holder go head implementing Transaction Details API with payer” & “payee” fields and present NULL values for all NPP (x2p101Payload ) fields in the response, as NPP transaction is not supported by Data Holder. Or Transaction Detail become an optional implementation. Can you please suggest the approach Data holder should take . | If you don't have the extended data then a 404 (Not Found) should be returned. The isDetailAvailable should be set to false for Get Transactions API calls in this instance if you don't support the NPP data. Until other NPP services are included in the transaction payload or the payload is amended, a transaction can only validly have extendedData if it was executed using the X2P01.01 overlay service. Other transactions should return false in the isDetailAvailable field and should return a 404 response if extended data is requested. Other transactions should give false in the isDetailAvailable field and should give a 404 if extended data is requested. CDR Support Portal Article - Handling transaction detail extendedData when NPP not supported |
| 443 | For cases where the bank does not hold the DirectDeibit authorisation data, what is the response that is expected in the output payload of the Direct Debit Authorisation APIs? | a good starting point would be these CDR Support Portal articles: Direct-Debit-length-of-historic-data Direct-Debits Direct-Debits-inclusion-with-recurring-payments CDR Support Portal Article - DirectDebit Authorisation API |
| 444 | Could you clarify the below section in the standards on the term base URI In the Client Authentication - Data Holders calling Data recipients section, aud - REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Data Recipient as the intended audience. The Data Recipient MUST verify that it is an intended audience for the token. Contents MUST be the base URI for the end point being accessed. If the DH is calling data recipient's arrangement revocation endpoint where data recipient's base uri is https://datarecipient.com.au/ the expected value in aud claim is "https://datarecipient.com.au/arrangements/revoke" or just "https://datarecipient.com.au/"? | It would be the RecipientBaseUri provided in the software statement assertion (SSA). In your example that would be "https://datarecipient.com.au/" CDR Support Portal Article - Authorisation aud claim |
| 447 | The CDR Rules, Schedule 3, subclause 2.1(2)(b)(ii) state that a customer is eligible if they are an account holder or secondary account holder for an account that 'is set up in such a way that it can be accessed online by the CDR customer.'. Is a customer who has not registered for internet or mobile banking (for any of their accounts with the data holder) an eligible customer, assuming internet/mobile banking is the only way to access their accounts online? The customer could access internet banking/mobile banking if they go through a registration process, but they have not gone through it yet, and therefore cannot currently perform any transactions online in relation to any of their accounts with the data holder | Below are some suggested articles which may help you as they address similar questions: Offline accounts Internet banking and accessibility requirements |
| 451 | As per description, it specifies that ‘Fees and charges applicable to the account based on the equivalent structure in Product Reference’ Can you please clarify, does it mean that we need to return the exact same structure and data as in Product Reference API that is applicable for this particular account, or if, for example, there is a fee that is usually applied to the type of product to which this account belongs, but this fee has been waived for this particular account, do we have to expose same structure as in Product Reference API but different data (showing that the fee that has been waived, or not showing that fee at all)? | This sentence was meant to imply that the way fees are presented for the account use the same BankingProductFee structure and you should be consistent in the naming and terminology (e.g. if you a saving account has an "EARLY_TERMINATION_FEE" then you should be consistent when presenting that fee for the account rather than calling it something else such as "Termination fees on early exit"). It is also meant that how you represent tiers, discounts etc. should be consistent between the PRD data and the fees, rates etc. applicable in the account data response. Noting that some fees and accounts may be grandfathered and no longer apply to the publicly available products so some variance is likely for some accounts. The fees for an account should only be those that apply to the given account (now that the product has been taken up by the customer and any fees have been negotiated or tailored). CDR Support Portal Article - Fees object of Get Account Details API |
Response pending
| Ticket # | Question | Answer |
|---|---|---|
| 107 | Answer in progress | |
| 139 | Answer in progress | |
| 174 | Answer in progress | |
| 189 | Answer in progress | |
| 196 | Answer in progress | |
| 203 | Answer in progress | |
| 209 | Answer in progress | |
| 214 | Answer in progress | |
| 221 | Answer in progress | |
| 225 | Answer in progress | |
| 232 | Answer in progress | |
| 244 | Answer in progress | |
| 250 | Answer in progress | |
| 256 | Answer in progress | |
| 257 | Answer in progress | |
| 259 | Answer in progress | |
| 261 | Answer in progress | |
| 263 | Answer in progress | |
| 265 | Answer in progress | |
| 268 | Answer in progress | |
| 283 | Answer in progress | |
| 290 | Answer in progress | |
| 291 | Answer in progress | |
| 292 | Answer in progress | |
| 293 | Answer in progress | |
| 299 | Answer in progress | |
| 301 | Answer in progress | |
| 303 | Answer in progress | |
| 308 | Answer in progress | |
| 310 | Answer in progress | |
| 311 | Answer in progress | |
| 312 | Answer in progress | |
| 318 | Answer in progress | |
| 319 | Answer in progress | |
| 321 | Answer in progress | |
| 323 | Answer in progress | |
| 324 | Answer in progress | |
| 329 | Answer in progress | |
| 331 | Answer in progress | |
| 333 | Answer in progress | |
| 334 | Answer in progress | |
| 335 | Answer in progress | |
| 336 | Answer in progress | |
| 337 | Answer in progress | |
| 338 | Answer in progress | |
| 339 | Answer in progress | |
| 340 | Answer in progress | |
| 341 | Answer in progress | |
| 346 | Answer in progress | |
| 347 | Answer in progress | |
| 350 | Answer in progress | |
| 351 | Answer in progress |
Question and answers
| # | Question | Answer/ Action |
|---|---|---|