ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 28 November 2024
When: Weekly every Thursday at 3pm-4:30pm AEST
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 5 min will be allowed for participants to join the call.
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 and present, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
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.
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.
⭐ indicates change from last week.
| Type | Updated | Links |
|---|---|---|
| Standards | Version 1.32.0 | Published: 21st of October 2024 Change log |
| Standards | Version 1.33.0 | Coming soon |
| Maintenance | Iteration 21 | Complete |
| Maintenance | Iteration 22 to commence in February 2025 | Registrations and invitations to be issued first week of December |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 22 November 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation ⭐ | Noting Paper 345 - Data Standards Body Capability, Consultation Processes and Operating Model | Link to consultation |
| Consultation ⭐ | Noting Paper 352 - Cost and change considerations | Link to consultation |
| Consultation | Noting Paper 355 - Deceptive Patterns Independent Health Check | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 357 - LCCD Benefit Workshop Summary | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 359 - Deceptive Patterns Health Check - Next Steps | No feedback sought Link to Noting Paper |
| Consultation ⭐ | Noting Paper 360 - Chair response letter statement of intent | Link to consultation |
| Guidance ⭐ | The ACCC has published new Guidance for accredited data recipients on completing biannual reporting forms under rule 9.4, which provides information on how particular questions in the reporting forms should be answered, including metrics related to disclosure consents. | - |
| Data Quality ⭐ | Question raised about data quality actions from April 2023 report | ACCC to give an update |
| End of Year | Calls remaining in 2024: - - - - 5 December 2024 |
Return on 16 January 2025 |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Christian |
None this week.
Questions will be received by the community via Microsoft Teams 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.
| Ticket # | Question | Answer |
|---|---|---|
| 2445 | This is in relation to: Change id token encryption documentation to allow for use in Hybrid flow and ACF · Issue 576 · ConsumerDataStandardsAustralia/standards-maintenance · GitHub We would like to clarify the requirement to support unencrypted ID tokens Currently we always encrypt ID Tokens regardless of whether the ADRs are using the Auth Code flow or Hybrid (We have checked and not all ADRs have switched to ACF as yet) So far, no problems as existing ADRs all work fine with our encrypted ID token, however, would like to confirm if there is an expectation by when data holders must switch to un-encrypted ID Tokens? |
ID token encryption is only required for hybrid flow and Data Holders have not been required to support hybrid flow since July 10th 2023. Have you attempted to encourage any ADRs that are registered for both hybrid flow and ACF, or still hybrid only, to transition to ACF only? I would be interested in hearing if they have had challenges or other reasons for not migrating yet. Once you decide to remove support, this should allow you to remove these encryption fields from your OIDD, ignore them in any future registration requests, and then stop encrypting ID tokens as a result. id_token_encrypted_response_alg id_token_encrypted_response_enc If you refer to Standards Maintenance issue #666 - Retirement of OIDC Hybrid Flow, which was included in Maintenance Iteration 21, it was proposed that hybrid flow is to be disallowed after 12th May 2025. |
| 2448 | Can you please clarify if the dynamic client registration response MUST contain authorization_signed_response_alg? In relation to open incident. We have been unable to register with a holder in the ecosystem to due a disagreement on the response data structure. Our client requires a value for authorization_signed_response_alg in the registration response. From the CDS Consumer Data Standards https://consumerdatastandardsaustralia.github.io/standards/#cdr-dynamic-client-registration-api_schemas_tocSregistrationproperties) authorization_signed_response_alg Enum conditional The JWS alg algorithm required for signing authorization responses. If this is specified, the response will be signed using JWS and the configured algorithm. The algorithm “none” is not allowed. Required if response_type of “code” is registered by the client. This is further inline with the underlying standard mentioning this field this is REQUIRED - JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://openid.net/specs/oauth-v2-jarm.html#name-client-metadata The counter argument posed by the holder is (quoted from a section of the CDS) Data Recipient Software Products Data Recipients MUST support [JARM] in accordance with [FAPI-1.0-Advanced] section 5.2.3.2. In addition, Data Recipients MUST request authorisation response signing using one of the authorization_signing_alg_values_supported values offered by the Data Holder. Data Recipients MAY request response encryption using one of the advertised encryption sets. Data Recipients MAY request no response encryption by omitting the values in their client registration. If authorization_signed_response_alg is omitted, the default algorithm is "PS256". |
The following statement: If authorization_signed_response_alg is omitted, the default algorithm is "PS256". is under the heading; Data Recipient Software Products and should be taken to be referring to the registration request. The Registration response schema, RegistrationProperties, states that authorization_signed_response_alg is: Required if response_type of “code” is registered by the client. The values that are supported for authorization_signed_response_alg are PS256 and ES256. |
| 2454 | As a data holder, we have been receiving requests to amend consents from few data recipients where the party initiating the amendment is a joint account holder, not the individual who initially created the consent. If User 1 creates a consent that includes Accounts A, B, and C, and there is User 2 who holds joint ownership of these three accounts with User 1, the question arises whether User 2 has the authority to amend the consent initially created by User 1, given that all three accounts in the consent are joint accounts. |
Under the CDR Rules, a person (including a joint account holder) can only amend their own consents and authorisations. Generally, a person cannot amend the consents or authorisations of another person, unless an appropriate arrangement is in place such as a power of attorney. However, data sharing from a joint account may also cease for other reasons that are independent to a consent or authorisation, such as: • a joint account holder has applied a non-disclosure option, which means joint account data cannot be shared at all • a joint account holder (the ‘non-requesting joint account holder’) has withdrawn the relevant approval • another provision of the rules applies – for example a consumer ceases to be ‘eligible’. Joint account holders may also make their own consumer data request, if the pre-approval or co-approval disclosure option applies to the account. See our Joint account implementation guidance for more information. We note your question states your organisation has “been receiving requests to amend consents from few data recipients where the party initiating the amendment is a joint account holder, not the individual who initially created the consent.” It is unclear as to how a data holder could receive a request to amend an authorisation where the amendment is initiated by a non-requesting joint account holder. We would welcome any further information that you may have on this. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |