Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 24th of March 2022

Jump to bottom
CDR API Stream edited this page Mar 24, 2022 · 5 revisions

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
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 16th of March 2022 Link to the agenda and minutes
Maintenance Meet next week 30th of March 2022
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 21st of March 2022 View in browser here
DSB Newsletter 18th of March 2022 View in browser here
DSB Newsletter Correction of links in 18th of March 2022 New open source design assets and prototypes for Consent Management (Data recipient): Collection and use
New open source design assets and prototypes for Consent Management (Data recipient): Disclosure consents
Updated page titles and hierarchy for Consent Management
New open source design assets and prototypes for Consent Management (Data recipient): Withdrawal
General updates and revisions to the CX Guidelines including additions to accommodate the energy sector, slight requirement modifications, and open source assets
Updated CX Checklist (on website) related to CX standards
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 15th of April 2022
Link to consultation
Design Paper Design Paper: Consumer Data Right Rules and Standards for the Telecommunications Sector Link to DSB GitHub
Link to Treasury page
CX Guidelines Updated v1.16.0 of the downloadable CX Checklist Link to the CX Guidelines
Knowledge Video 21: Decision Proposal 240 - narrated by Neale Morison (22/03/2022) Link to video

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

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
1347 Taken on notice from 10th of February 2022 - Can secondary users be classified as vulnerable? We have published new public guidance today that we trust will answer your question.
You can find the new guidance here: https://cdr-support.zendesk.com/hc/en-us/articles/4559246860047
1351 Taken on notice from 10th of February 2022 - If a vulnerable flag is removed should historical arrangements be visible to all parties? We have published new public guidance today that we trust will answer your question.
You can find the new guidance here: https://cdr-support.zendesk.com/hc/en-us/articles/4559246860047
1369 At present the rules make provision for managing vulnerable customers in relation to sharing data (Rules 3.5(1) and 4.7(1)) and in relation to joint accounts (Rule 4A.15). However there appears no relief in relation to secondary users who are vulnerable. At present it appears mandatory to provide the account owner with visibility and control over the actions of a secondary user (Rules 1.15(5) and 4.28). A common secondary user scenario is that of a credit card with a secondary card holder. It is likely that a vulnerable customer would be a secondary card holder and thus a secondary user. Is it intended that secondary users are not protected from harm? If this logic is incorrect, can you please explain how vulnerable secondary users are protected. Thanks. We have just published new public guidance today that we trust will answer your question.
You can find this new guidance here: https://cdr-support.zendesk.com/hc/en-us/articles/4559246860047
1397 As per standards, plan eligibility details can be provided for existing accounts in the GetAccountDetails API > ElectricityContract > PlanEligibility (optional) section.
There are some plan eligibility managed in system and some are managed through business process using work instruction etc.,
Can you please confirm if ok to provide only the eligibility managed in system?
Note: Customer is already onboarded & account is open/active based on eligibility (at the point of establishing contract).		 For public tariffs the response should contain all forms of eligibility whether automated or not.
For Account Details, given the customer is already onboarded, plan eligibility can be left out. The customer must have been eligible for the plan to be originated to start with.
1408 With reference to point 4 above - non-normative examples
https://consumerdatastandardsaustralia.github.io/standards/?examples#security-endpoints
Non-Normative Example
## Request
GET /.well-known/openid-configuration HTTP/1.1
Response as per the standards
"response_types_supported": ["code id_token"],
"response_modes_supported": ["fragment"],
"id_token_signing_alg_values_supported": ["ES256", "PS256"],
"id_token_encryption_alg_values_supported": [ "RSA-OAEP", "RSA-OAEP-256", "dir", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW", "A128KW", "A192KW", "A256KW", "A128GCMKW", "A192GCMKW", "A256GCMKW" ],
"id_token_encryption_enc_values_supported": [ "A128CBC-HS256", "A192CBC-HS384", "A256CBC-HS512", "A128GCM", "A192GCM", "A256GCM" ],
What is missing from the response?
- "response_types" field values ["code"]
- "authorization_signed_response_alg" ,
- "authorization_encrypted_response_alg",
- "authorization_encrypted_response_enc"		 These are being updated under a change request being worked on in Maintenance Iteration 10 (this iteration) so they are intended for correction in v1.17.0 of the data standards.
1416 Please confirm, if Hybrid flow is implemented then “ID Token as detached signature” implementation listed as part of FAPI 1.0 Advanced is required or not?
We understand that JARM is not required with Hybrid flow. Is that a correct understanding?		 Your understanding looks correct. If Data Holders support the Hybrid flow they must continue to do so by signing AND encrypting the ID token such that it can be used as a detached signature. Data Holders MAY drop ID Token encryption if they use JARM which can only be used for the Authorisation Code Flow.
1417 For Get Transaction for Account if the text query is not implemented by the DH then can you share a sample response please You would need to populate the isQueryParamUnsupported in the meta object as part of the response. You would return the full unfiltered result set in the data object.
1419 Could you let us know the expected properties for the Links Pagination [1] when a request (e.g. GET cds-au/v1/banking/accounts) returns only one total page? Currently, what we are getting is the following for the link section of the response.
"links":{
"self":"https:///cds-au/v1/banking/accounts?page=1&page-size=25",
"first":"https:///cds-au/v1/banking/accounts?page=1&page-size=25",
"last":"https:///cds-au/v1/banking/accounts?page=1&page-size=25"
}
[1] https://consumerdatastandardsaustralia.github.io/standards/#tocSlinkspaginated 		the example response you provide is correct. LinksPaginated includes a number of optional fields which are to be returned depending on the page location in the result set. Since there is only one page of results obtainable using the pagination filters, you would not present a "next" and "prev" value.
1432 The CDR is specifying a variety of error URNs to be used in responses to DRs at https://consumerdatastandardsaustralia.github.io/standards/#error-codes. Can DHs respond with self made URNs for cases that are not specified in the CDS? Or should DHs only use specified URLs and use urn:au-cds:error:cds-all:GeneralError/Expected or urn:au-cds:error:cds-all:
GeneralError/Unexpected for unspecified cases.		 Yes you can use your own URN but it must be presented as a custom error code not presented in the URN field.There is further information here: https://consumerdatastandardsaustralia.github.io/standards/#error-codes
Data Holders implementing custom error codes must choose one of the fallback CDR error codes for use in the "urn" field so that ADRs can reliably map custom error codes for each DH to a generalised CDR error.

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