ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 9th of November 2023
When: Weekly every Thursday at 3pm-4:30pm AEDT
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, 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.
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 | Topic | Update |
|---|---|---|
| Standards | Version 1.27.0 | Published: 10th October 2023 Change log |
| Standards | Version 1.28.0 Draft Standards for Non-Bank Lending Candidate Standards for Decision Proposal 306 |
View the Staging version of Standards here. |
| Maintenance ⭐ | Maintenance Iteration 17 | Met on the 1st of November 2023 Next meet on the 15th of November 2023 |
| Maintenance | Maintenance Iteration 17 | All agendas and meeting minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 3rd of November 2023 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 280: The CX of Authentication Uplift | No Close Date Link to consultation |
| Consultation | Noting Paper 307 - LCCD Consultation Approach | No Close Date Link to consultation Video |
| Consultation | Noting Paper 308 - Categories of Standards | No Close Date Link to consultation |
| Consultation | Decision Proposal 318 - Non-Bank Lending Standards |
Feedback Closes: 8th of December 2023 Link to consultation |
| Consultation | Noting Paper 326 - Authentication Uplift Context |
Feedback Closes: 15th of November 2023 Link to consultation |
| Consultation | Decision Proposal 327 - Authentication Uplift Phase 1 |
Feedback Closes: 15th of November 2023 Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Decision Proposal 333 - Business Consumer Provisions | Feedback Closes: 21st November 2023 Link to consultation |
| Consultation | Decision Proposal 334 - Data Holder Dashboards | Feedback Closes: 21st November 2023 Link to consultation |
| Video ⭐ | Decision Proposal 318 - narrated by Neale Morison (03/11/2023) | View the video |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
| ACCC | Register and Accreditation Application Platform | Eva |
| ACCC | Conformance Test Suite | Christian |
| ACCC | Business Operations | Lawrence |
| DSB | Consumer Experience | Mike |
| DSB | Non-Bank Lending | Nils |
Topic: Authentication Uplift - Noting Paper 326 and Decision Proposal 327
Presenter: Mark Verstege, Data Standards Body
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 |
|---|---|---|
| 1735 | I have question related to recent v1.18.0 changes regarding timeOfUse rates and TimeString. unclear on how we should behave between daylight saving time and non daylight time. So the business case is this. You have a peak period we bill you. might be 7pm - 11pm. When not in daylight savings we will be billing you 7pm - 11pm. whe move into daylight savings we bill also 7pm - 11pm. We don’t shift the time i.e. start billing 8pm-12am. the account is located in VIC and the request is made today (Not Daylight savings time) response would be "startTime": "10:00:00+10:00", "endTime": "23:00:00+10:00" the account is located in VIC and the request is made December first response would be "startTime": "10:00:00+11:00", "endTime": "23:00:00+11:00" |
We have been consulting on this specific issue in the current maintenance iteration - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/613 You can review the proposed change to help address this issue in this comment - https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/613#issuecomment-1776516757 Feel free to provide any feedback you have on this. If no issues to the proposal are raised, we would propose this change for the Chairs approval and incorporate it in the next version of the standards. |
| 1888 | We are undertaking a data mapping exercise and would like to know if there is a list of energy concessions with the concession type (Fixed, %, Variable). This should be standard for all retailers |
If you are looking for publicly available plan information (which includes available discounts and incentives as part of the plan), you can find it via the Energy Product Reference Data APIs, specifically via the Get Generic Plan Detail API. This is a publicly accessible endpoint and anyone can access it. If you are looking for concessions applicable to a given consumer account, you can do so via the Get Concessions API. Note that this is an authenticated API, meaning only an ADR can call and get data if the consumer consents to sharing the data. |
| 2112 | For the DCR register request sent by the ADR, Why is the requirement for the request body to be a JWT instead of JSON when we are authenticating the requests through mTLS? | In the Client Authentication section the standards state the mTLS is not to be used for client authentication. The JWT presentation of the client registration performs a proxy for client authentication before the client is registered and a client_id is issued by the DH. This binds the SSA to the request made by the anonymous client seeking registration. The DH can then validate the outer registration JWT by checking it was signed using the key of the ADR listed via the ADR's jwks_uri endpoint which is provided in the SSA JWT signed by the Register. The DH can validate that the SSA was signed using the key of the Register, by verifying it against the associated JWK published at the CDR Register JWKS endpoint. |
| 2147 | Just double checking, that the intrinsic greenpower is only talking about the greenpower scheme? Therefore, any other scheme should not be passed in the get energy account details? Reason I ask is because we have 100% carbon neutral included within some of our plans, but could be misleading as its not greenpower. (Carbon neutral and greenpower are two different things). Based on our current understanding, we dont intend to pass any value in the intrinsic green power rate section as ours is not greenpower. But looking to clarify in case we have this wrong. |
This structure, including the field is based on the current plan information the retailer provides EME/VEC. My suggestion would be to base it on what you currently provide in such plans/scenarios to EME. |
| 2149 Part 1 | I believe the Get Account Details is meant to return account specific information while the Get Product Details is meant to return general product information. Using the scenario below, can you please advise what we fees we should include in Get Account Details ? 1. John has a savings account. 2. The bank provided him with a list of fees and services offered. 3. Some of the fees and services offered by the bank are : a) Purchase bank cheque : $8 b) Replace bank cheque : $18 c) Company search fee : $30 4. Since John did not utilise any of the above services, do we exclude them from Get Account Details ? Get Account Details provides the productCategory and productName for a given account. ADRs can use this information to call the Get Product Details to obtain general product fees. This will provide account specific fees and general product fees. "Get Account Details provides the productCategory and productName for a given account. ADRs can use this information to call the Get Product Details to obtain general product fees. This will provide account specific fees and general product fees." Would like to clarify the above sentences in my original ticket. It should be : "Since the Get Account Details provides the ADRs with productCategory and productName for a given account, they could use this information to call the Get Product Details to get a full picture of what are the account specific fees versus product specific fees. For example the ADR could see that the customer paying $10 for the account keeping fees while the it's advertised as $40. |
In response to your question: Q: Using the scenario below, can you please advise what we fees we should include in Get Account Details ? 1. John has a savings account. 2. The bank provided him with a list of fees and services offered. 3. Some of the fees and services offered by the bank are : a) Purchase bank cheque : $8 b) Replace bank cheque : $18 c) Company search fee : $30 4. Since John did not utilise any of the above services, do we exclude them from Get Account Details ? A: Yes you need to include these fees in Get Account Details as they are still fees that could be incurred at any time. To your other point: "Get Account Details provides the productCategory and productName for a given account. ADRs can use this information to call the Get Product Details to obtain general product fees. This will provide account specific fees and general product fees." This is not the case. There is no reliable linkage between Get Product Details and Get Account Details. There are various reasons for this but come specific reasons are: The account that John has may be for a product that is no longer offered so it no longer appears in Get Product Details The account that John has may be contracted so the fees offered to a new customer may not the be the fees he is contractually entitled to The account that John has may be the same category and name as a product on market but they could be completely different products and the name has been recycled In any case, a decision was taken early that there is no connection, explicit or implicit, between Get Product Details and Get Account Details. Get Account Details should be treated as an isolated endpoint. |
| 2149 Part 2 | Lets say the 'General fees and services' state that the account keeping fee is $50 per year but John is only charged $10 per year, what do we return in terms of the account keeping fee | Account Details would have the fees that may be charged, not the fees that have been charged. The actual charged fee would appear in transaction history with the type of FEE. |
| 2149 Part 3 | Just to be 100% sure, using my example below, when John’s ADR calls the Get Account Details API, we should return the following fees ? a) Purchase bank cheque : $8 è general fee published to the public and the customer’s PDS b) Replace bank cheque : $18 è general fee published to the public and the customer’s PDS c) Company search fee : $30 è general fee published to the public and the customer’s PDS d)Account keeping fee : $50 è general fee published to the public and the customer’s PDS Although John’s account keeping fee is $10 per year, we do not show this in the Get Account Details API because this will appear in the transaction history. |
To be clear, my expectation for the account keeping fee (given that seems to be the crux of the question): If John will always get charged $10 per year because that is what he negotiated or was offered because of a past then account details should show the Account Keeping Fee as $10 If John may be charged $50 but has been charged $10 because the fee is variable and may change with circumstance then the Account Keeping Fee should probably be presented as a VARIABLE fee with $50 listed as the maximum If John could be charged $50 but is only charged $10 because of a discount that he is eligible for then the Account Keeping Fee should be shown as $50 but it should have a discount listed with it indicating that $40 will be discounted given certain eligibility criteria Note that there are two principles here: 1. ) The fees shown in account details should be specific to the actual account being shown which may have been tailored in some way 2.) There is no requirement to link products on market (ie. in Get Product Details) with Account Details. In fact this is explicit not supported and actively discouraged due to the fact that accounts conditions on market can diverge from contracted accounts and accounts can be grandfathered |
| 2158 | Just a question I was hoping to get answered or raised in the CDR Implementation Weekly Call this week if possible. Query on Content Type and Accept Header Field – Consumer Data Standards Australia (zendesk.com) |
Content Type: Question 1) What are the Valid Content Type Header Values, and should we consider only the references given in non-normative example as the only valid values? Content type values are case insensitive (see https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.5, and https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1) and a character set can be provided but isn't required. Only UTF-8 is accepted as a character set. For the resource API calls, "application/json" is defined as the media type. Where a payload is presented to the endpoint such as the oAuth Token endpoint of the CDR Arrangement Revocation endpoint "application/x-www-form-urlencoded" is required. This is called out in the Data Standards or the relevant normative reference (for example, the Pushed Authorization Request specification defines the media type and character set. The DCR APIs POSTing a registration request use media type "application/jwt". See "Registration Request using JWT" in the Client Registration section for details. Accept Header: Question 1) What are the Valid Accept Header Values, and should we consider only the references given in non-normative example as the only valid values as given below? "application/json" is currently the only response media type accepted. Question 2) Should the Request be rejected if the Accept Encoding Header value is not as given above with 406 Error Response? If the media type that the client is requesting in the Accept header is not supported, then yes the 406 error response must be provided. |
| 2161 | Consent authorization and consent revocation processes are internally using the infosec API- /as/token.oauth2 to authenticate resource API (consent/v1/consents API- PING CDR API to create consents) as it is a protected resource. Do we need to count this call as part of high priority invocation for admin API? | internal APIs such as your Ping CDR API aren't defined by the Data Standards and aren't included in invocation counts. It is only the externally facing oAuth endpoints defined as required by the Data Standards that are included in the invocation counts. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |