ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14th of July 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
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

Primary Australia: +61-2-9338-2221
Quick Dial: +61-2-9338-2221,,1650705270##
Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
Meeting Number/Access Code: 165 070 5270

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

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.

House Keeping

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.

Community Guidelines

By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.

Updates

Type	Topic	Update
Standards	Version 1.17.0 Published	Link to change log here
Standards	Version 1.18.0 to incorporate changes from Maintenance Iteration 11	Timing to be confirmed
Maintenance	Maintenance Iteration 12	Planned to commence next week on the 20th of July 2022
Community Guidelines	Updates to the Community Guidelines to Version 1.3	Link to the Community Guidelines
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	1st of July 2022	View in browser here
DSB Newsletter	8th of July 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
Noting Paper	Noting Paper 255 - Approach to Telco Sector Standards	Link to consultation
Consultation	Decision Proposal 256 - Telco Endpoints Feedback closes: 5th of August 2022	Link to consultation
Consultation	Decision Proposal 257 - Customer Data Payloads for Telco Feedback closes: 5th of August 2022	Link to consultation
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Workshop	DSB - Energy Sector: Historical Data Sharing - Workshop	Link to Registration: Eventbrite

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	Amy Nussbaumer
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Register	Ivan Hosgood
DSB	Technical Standards - Banking	Mark Verstege
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Engineering	James Bligh

Presentation

None this week.

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.

In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.

Answer provided

Ticket #	Question	Answer
823	Comment on an article: https://cdr-support.zendesk.com/hc/en-us/articles/360004324176-Data-Holder-sector-identifier-uri-Support#comment_360000422056	This issue is being covered through change request 484 and is being worked through the standards maintenance process
1604	Decision Proposal 209 had the following statement, which indicates that ID Tokens returned from the Authorisation End Point do NOT need to be encrypted: ID Token Encryption changed from MUST to MAY o ID Tokens MUST be signed and MAY be encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point. However, the published standards indicate that ID Tokens returned from the Authorisation End Point MUST be encrypted: https://consumerdatastandardsaustralia.github.io/standards/#tokens Please clarify which is correct?	This is in regards to the move to Authorisation Code Flow. In that instance there is no longer the same need to issue the ID Token as a detached signature. We retain signing and encryption of the Hybrid Flow.
1616	As part of the Security Information Profile changes required by Sept 16th (captured in the Future Date obligations section of the Consumer Data Standards), there is mention that DHs will no longer support refresh token cycling. In a further section (under Security Profile -> Tokens) of the Consumer Data Standard, it elaborates on this requirement and states that: "Data Holders MUST NOT cycle refresh tokens (rotation). In other words, Refresh Tokens SHOULD be issued with an "exp" equal to the sharing duration authorised by the Customer." Given the above requirements, what is the expected behaviour of a call made to the token endpoint with a grant_type of "refresh_token"? Mainly, should we issue a new access token, but not return a new refresh_token, in the understanding that the originally issued refresh_token will remain active and can be re-used? Or should we invalidate the current refresh_token and issue a newly minted access_token and a newly minted refresh_token? It is unclear if we are able to create new refresh_tokens and return them? Can you please clarify?	section 6 of RFC6749 covers this. https://datatracker.ietf.org/doc/html/rfc6749#section-6 If you are using a grant type of refresh_token to obtain a new access token, the Authorisation Server MAY issue a new refresh token. Given refresh token cycling is not supported going forwards you would omit or replay the refresh token. You may want to validate this with you IAM provider to understand how they support this.
1617	In the Future Dated obligations section of the Consumer Data Standards, for the obligation coming into effect on the 16th Sept 2022 (titled Information Security profile), there is an entry which reads as follows: "Enforces additional requirements for authorisation code, token and request object use" We are unable to determine exactly what is meant by this requirement? Can you please elaborate? When we read the Advanced FAPI specification, it is unclear how the above line relates to the specification. Could you please help us understand this requirement?	This appears to be a transposition error from the July 4th obligations. Phase 2 does include enhancements with FAPI 1.0 adoption that also provide requirements such as mandating PAR that further enforce how request objects are used. Phase 2 also allows for Authorisation Code Flow support that changes token usage.
1627	We request this field ‘dailyCharge’ within EnergyPlanControlledLoad to be made ‘optional’ as In data standards this field is marked as ‘mandatory’. However, 'dailyCharge' may/ may not be applicable for Controlled load rate types Please find the reference: https://www.canstarblue.com.au/electricity/controlled-load-tariff-can-save-money/ Note: Similar to South Australia, there is only one controlled load option, and it’s almost always referred to as a ‘dedicated circuit’ on electricity price fact sheets. Additionally, there are no extra supply charges for this tariff.	For all changes to the Consumer Data Standards we ask that you raise this as part of the Standards Maintenance repository: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance
1630	As per CDS for FAPI 1.0 phase 2, "Authorisation request data MUST only be accepted using PAR" and "Data Holders MUST reject authorisation request containing "request" parameter". In order to accept only PAR, we need to always include 'require_pushed_authorization_requests' parameter in the Client Metadata as per https://datatracker.ietf.org/doc/html/rfc9126. But in the CDS v1.17.0 (https://consumerdatastandardsaustralia.github.io/standards/#client-registration), section Client Registration under 'Client Metadata' this parameter (require_pushed_authorization_requests) is not present. Please check and confirm our understanding.	"require_pushed_authorization_requests" is an authorisation server metadata parameter hosted by the Data Holder under their well-known OpenID Provider Configuration End Point. This parameter is not part of the client registration negotiation.