ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 24th of February 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

CDR Implementation Call Banner

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.16.0 Published Link to change log here
Maintenance 10th Maintenance Iteration Commenced on the 16th of February 2022
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes (16 February 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 16th of February 2022 View in browser here
DSB Newsletter 18th of February 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date Link to consultation
Action Presentation on Register changes for V2 Today
Action Article on Token Expiry and mutability Planned and in draft

CDR Stream Updates

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

Organisation Stream Member
ACCC CDR Register Hopeson Chiao
ACCC CTS Andrea Gibney
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

Title: Register changes Presenter: Ivan Hosgood Link: https://consumerdatastandardsaustralia.github.io/standards/#register-apis

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

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

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1098 CDR Rule 1.15(3)(g) refers to having to include an entry / update on a consumer dashboard where the data disclosed to an accredited person is due to a data correction raised by a customer under s56EN(4). As per these Zendesk guidance (PS11 & PS13) and OAIC guidance (11.44), when a customer raises a correction request under the Privacy Safeguards, the data holder is to notify the consumer by electronic means, which can be satisfied by providing a notice via email or over the consumer dashboard. We have chosen to provide the notice via email on this basis and understand the intent of this is to ensure that while the customer is appropriately notified, they are not over notified causing notification fatigue. Is there intent to update Rule 1.15(3)(g) to reflect the option of either a dashboard or email notification? Separately we note that this optionality is provided in CDR Rule 7.10(1) Note2 where the written notice is stated as “could” be given through the dashboard. We note this Zendesk article makes references to this CDR rule and has not clarified what is expected for this requirement. If Rule 1.15(3)(g) is not optional, can you clarify whether the intention is to provide another method for the customer to view the notice required under s7.10(1)? A Data Holder is unable to push corrected data/info to an accredited person, and relies upon the customer to reauthorise (for one-off consents) or the ADR to call the relevant APIs (for long-lived consent) and this has been reflected in this ACCC guidance. Hence a Data Holder will not be able to distinguish or record whether an authorisation/API call is for a correction or otherwise. Thank you for sending this query through and please accept our apologies for the long delay in getting back to you. Our proposed response to this query is as follows: We note there are two different obligations that are relevant to this question, as set out in s 56EN(3)/Rule 7.10, and Rule 1.15(3)(g). Firstly, there is an obligation created by s 56EN(3) for all CDR participants to notify a consumer if incorrect CDR data about them has been disclosed, in accordance with the CDR Rules. Rule 7.10 further provides that where data is disclosed to an accredited person, the s 56EN(3) notification must: 1. Include the following details: i. the accredited person(s) to whom the CDR data was disclosed; ii. the date of the disclosure; and iii. the CDR data that was incorrect. 2. notify the CDR consumer that they can request that the CDR participant disclose the corrected CDR data to the accredited person(s) and that if such a request is made, the corrected CDR data will be disclosed. 3. Be electronic, and could be via the dashboard or email. 4. Be made as soon as practicable, and no later than 5 business days after the CDR participant becomes aware of the error. As set out in 11.44 of the OAIC’s CDR Privacy Safeguard Guidelines, a CDR participant must give the 7.10 notice in writing via electronic means, which may be done via email or by updating the dashboard. Secondly, there is a separate obligation created by Rule 1.15(3)(g) for a data holder to ensure it provides all CDR consumers with an online service (dashboard) that contains a range of information, including the details of each authorisation to disclose CDR data made (and where a disclosure is pursuant to a correction request made under subsection 56EN(4) of the Act). Where a data holder has disclosed corrected data pursuant to a consumer request made under s 56EN(4), both the above obligations are triggered and the data holder may choose to meet both obligations by updating/notifying via the dashboard. However, we note a data holder is not able to meet both requirements by sending an email - as this is only an option under R 7.10. It is up to the data holder if they choose to send an email pursuant to R 7.10.
1294 The data holder report provides the following guidance: A reference to a 'refusal' to disclose CDR data is intended to cover all refusals to disclose CDR data. For the avoidance of doubt, circumstances where the data holder must report on the number of refusals to disclose CDR data include: 1 refusals for reasons specified in the data standards (for example, a refusal to disclose CDR data because the number of requests received exceeded the service level thresholds in the Non-Functional Requirements section of the data standards), 2 refusals where it is considered necessary to prevent physical or financial harm or abuse, 3 refusals where the data holder has reasonable grounds to believe disclosure of some or all of the requested CDR data would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder’s ICT systems (for example, a refusal to disclose CDR data in response to a valid security concern such as a denial of service attack), 4 refusals where the request related to an account that is blocked or suspended, and 5 any other reason the data holder has refused to disclose CDR data in response to a request. My understanding is that the HTTP response codes 429 and 403 are reportable 'refusal to disclose', as per https://consumerdatastandardsaustralia.github.io/standards/#exemptions-to-protect-service. Can you please confirm if data holders are required report on any other circumstances or HTTP response codes as per point 5? As per previous published Guidance, error codes 403, 404, 422, and 429 may be returned in cases where a consumer data request received by a data holder: - may cause physical or financial harm or abuse, - would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder's ICT systems (for example, during a denial of service attack), - relates to an account that is blocked or suspended, - exceeds the service level thresholds in the Non-Functional Requirements section of the data standards. As stated in the guidance, the above list is non-exhaustive and as such, when completing the rule 9.4 report, please indicate all of the error codes returned when the data holder refused to disclose data, including outside of the above circumstances.
1344 Energy APIs : Get Billing and Get Invoicing - Adjustments: If there is an adjustment that applies to the customer's bill i.e. when a prior bill period is “adjusted” or corrected (i.e. due to any revised usage data) and a revised invoice is not issued Is this understanding correct that such adjustments can be included in the "EnergyBillingOtherTransaction" as this section has "start date & end date" where the adjustment period can be passed along with the adjusted amount details There are array of adjustment objects within usage and demand transactions, you can view them here - https://consumerdatastandardsaustralia.github.io/standards/index.html#tocSenergybillingtransaction. The adjustment would be included based on its type (e.g. if its adjustments for usage charges, include them in the adjustment object of usage transactions). There is a CR that has been raised to include adjustments object within otherCharges for adjustments that are not related to usage or demand based charges - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/438. Feel free to provide any feedback you have there.
1345 CDR Arrangement Revocation End Point: clarification on cdr_arrangement_jwt Would it be possible to add more information on the technical details around cdr_arrangement_jwt which needs to be supported by all participants this year especially around: * accepted signing algorithm: are we expected to use PS256 or ES256 similar to FAPI 1.0 (https://openid.net/specs/openid-financial-api-part-2-1_0.html#algorithm-considerations) considering the endpoint is not part of FAPI? * if yes, could we revisit the non-normative example in CDS? The current sample uses HS256 algorithm which is a symmetrical algorithm and may not be appropriate algorithm (and potentially caused confusion by implementers) used for this purpose. Thanks for your question. The CDR does have JWT signing requirements in addition to OIDC/FAPI, however, the intention has always been to align to the FAPI requirements you have linked to in your query Section 8.6 FAPI-RW-Draft. The symmetric HS256 reference in the non-normative example is a documentation error. I have raised issue #482 in the standards maintenance repo in order to track and address this error. Thank you for highlighting this error, it really helps to advance our documentation.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.