ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14th of April 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.1 Published Link to change log here
Implementation Call Cancelled for next week: 21st of April 2022 Updates have been sent out to calendar invitations
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 13th of April 2022 Link to the agenda and minutes
Maintenance Maintenance Iteration 11 will commence on the 27th of April 2022 Invitations have been sent out to all current attendees
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 6th of April 2022 View in browser here
DSB Newsletter 8th of April 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
Consultation Decision Proposal 240 - ADR Metrics Feedback closes 27th of May 2022 Link to consultation
Consultation Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation Link to consultation
CX Guidelines CX artefacts - Consumer dashboard variation for Trusted Adviser disclosure consents New CX artefacts and guidelines to support Consent Management (Data recipient): Disclosure consents, Trusted Advisers disclosure consent. Consent Management (Data recipient) artefacts provide implementation examples to reflect the new rules on TA disclosure consents, and the CX standards introduced in v1.16.0, related to Disclosure Consent: Non-Accredited Person Disclosure Notification. CX Checklist (on website) includes key requirements and guidelines related to TA disclosure consents, see checklist references starting with 4CM1.04.
Knowledge [23] CDS 1.16.1 Release Walkthrough and Changes - with Jarryd Judd (14/04/2022) Link to Video
Caretaker "During the caretaker period, the business of government continues and ordinary matters of administration still need to be addressed.", from Section 2.4 of the Caretaker Convention Guidelines. The making and amending of the non-legislative Data Standard instruments are considered an ordinary matter of administration. Decision Proposal feedback closure dates will be adjusted to reflect this.

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 Emma Harvey
ACCC CTS Andrea Gibney
DSB CX Standards Eunice Ching
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy James Bligh
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

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: #747194

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
1406 In the phased approach to roll out the FAPI 1.0 changes (Decision Proposal 209), it is mentioned that phase 1 should be supported as soon as possible (before the obligation date). "Phase 1 changes should be supported by Data Recipients and Data Holders as soon as possible but no later than the obligation date." But this is not mentioned for phase 2 and 3. Doues this mean phase 2 & 3 cannot be supported before the obligation date? Now that DP209 has been converted into data standards, I'd recommend reviewing the statements in the standards with respect to the phasing. There are a number of elements that can be supported earlier than their mandatory phasing, for example the Authorisation Code Flow and PKCE.
1413 Is an empty string a "suitable default", or is the expectation that any "suitable default" would validate as a DateString? Does this apply? https://cdr-support.zendesk.com/hc/en-us/articles/900002616823-Mandatory-Fields-with-no-value-present an empty string is not itself a valid DateString so it couldn't be used as a default. The "empty string" imparts specific meaning which is defined in the Payload Conventions (and copied below). Is there a specific API response that is off issue with returning a valid date string? Empty/Null Fields An empty field (ie. a field that is not present in a payload) will be considered equivalent with a field that is present with a null value. An empty string (“”) is not considered to be equivalent to null. A Boolean value of false is not considered to be equivalent to null. Optional Boolean fields, by implication, have three possible values: true, false and indeterminate (ie. null).
1433 I have a query regarding the usage and obligation on cdr_arrangement_jwt. Under CDR Arrangement Revocation Endpoint - form parameter method, it is noted that data holders MUST use this method. This change came into v1.15.0 and I could not find obligation dates tied to this item (in contrast ADR hosted endpoint does have future dates). Additionally, the example of ADRs calling DHs on the right hand side does not have cdr_arrangement_jwt noted anywhere. Could you please clarify, with examples, what the current requirement is for DHs and ADRs for the DH-hosted Arrangement Revocation Endpoint, e.g: Is the example on the right hand side accurate, or outdated? Is form parameter method currently under obligation for DHs, or is it future dated? There is a documentation issue in the Data Standards that should clarify your questions: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/503. There is no obligation date for Data Holders because Data Holders already support the CDR Arrangement Form Parameter method. The CDR Arrangement JWT method was introduced in v1.15.0 for Data Recipient hosted endpoints. It appears that the code that was staged for Issue #426 did not correctly merge and build into the v1.15.0 release branch and this has been carried into the current release. Specifically, the section for the CDR Arrangement Form Parameter method was lost and the CDR Arrangement JWT method was included under the wrong heading. Data Holders are to only implement the CDR Arrangement Form Parameter method as has been the case all along where the cdr_arrangement_id is presented to the Data Holder's endpoint. The change for Issue #426 was specifically introducing the CDR Arrangement JWT method for the Data Recipient hosted endpoint. This section will be remediated in the current release (v1.17.0) due out in the next couple of weeks. See https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/503 for details.
1440 Context: V1.15 of the CDR Standards introduced a change requiring data holders to support the CDR Arrangement Form Parameter Method. Current wording for Data Holder Hosted Endpoints is that "Data Holders MUST only support "CDR Arrangement Form Parameter" method". Questions: - When is the Future Dated Obligation for this change? The current version of the standards read as if this came into effect immediately with V1.15. - What error should we return to ADRs who are not providing a cdr_arrangement_jwt? Should there be a period of transition before we disallow our mutual customers from being able to revoke a consent via an ADR not supporting this method. - When will this be implemented into the CTS? We have discussed this with the CTS team and we understand it is not currently in CTS V3.4.1. This is a documentation merge issue. It appears that the code that was staged for Issue #426 did not correctly merge and build into the v1.15.0 release branch and this has been carried into the current release. Specifically, the section for the CDR Arrangement Form Parameter method was lost and the CDR Arrangement JWT method was included under the wrong heading. Data Holders are to only implement the CDR Arrangement Form Parameter method as has been the case all along where the cdr_arrangement_id is presented to the Data Holder's endpoint. The change for Issue #426 was specifically introducing the CDR Arrangement JWT method for the Data Recipient hosted endpoint. This section will be remediated in the current release (v1.17.0) due out in the next couple of weeks. This will correctly read as follows: CDR Arrangement Form Parameter method The request MUST include the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body: - cdr_arrangement_id: The ID of the arrangement that the client wants to revoke. CDR Arrangement JWT method The request MUST include the following parameters using the application/x-www-form-urlencoded format in the HTTP request entity-body: - cdr_arrangement_jwt: A signed JWT that includes the cdr_arrangement_id. The cdr_arrangement_jwt MUST be a newly signed JWT with the following parameters in accordance with [JWT]: - cdr_arrangement_id: The ID of the arrangement that the client wants to revoke.
1468 Wondering whether data holders and accredited data recipients (under reciprocal data sharing arrangements) are required to share data with requesting persons in other sectors. For instance, can banking information be shared to a telco or energy company? All data holders are required to share data with any accredited data recipient. Organisations from any sector can apply to become registered as an accredited data recipient.
1473 Under 'DEMAND (Energy Billing Demand Transaction)' section in Get Billing For Account CDR Energy APIfield - "transactionUType" has 5 enums : usage, demand, onceOff, otherCharges & payment Qs. Where there are multiple transactions applicable under 'transactionUType' is the expectation to repeat transactionUType per transaction i.e. e.g. A scenario where 3 transaction types applicable for an account say Usage , demand & payment; Do we need to repeat 'transactionUType' field along with each transaction type as below: "transactionUType": "usage", "usage": { usage body } "transactionUType": "demand", "demand": { demand body } "transactionUType": "payment", "payment": { payment body } Note: The current Non-Normative example for same within the standards are bit unclear. That is correct. The EnergyBillingListResponse which is returned as part of "Get Billing For Account" is an array of "transactions". This allows providing different transaction types within a response array, and the value of "transactionUType" helps determine the type of transaction.

Useful Links

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