DSB Maintenance Iteration 11: Agenda & Meeting Notes (25 May 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki
Date and time: 25/05/2022, 2:00pm – 4:00pm AEST
Location: WebEx
Dial-in details:
- https://treasuryau.webex.com/treasuryau/j.php?MTID=m1d45159837de8df8bae6d3b8bb693cc3
- Dial In Number: +61 2 9338 2221
- Dial In Access Code: 2652 195 1973
- Quick Dial: +61-2-9338-2221,,26532937148## Australia Toll
Chair: Hemang Rathod, DSB
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 249
Recording
The Maintenance Iteration Calls are recorded for note taking purposes only. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material will be provided without the participant's consent. Participants may email [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.
Agenda
- Introductions
- Outstanding Actions
- Release plan
- Open / Active Decision Proposals
- Iteration 11 issues
- CRs for discussion
- Any other business
- Next Steps
Meeting notes
Introductions
This week is the third call of the 11th maintenance iteration.
The purpose of the meeting is to confirm the candidates that we anticipate completing in the 11th maintenance iteration.
- Housekeeping
- Agree and finalise iteration candidates for MI11
- Discuss first set of proposed CRs
Outstanding Actions
Energy
- DSB/AEMO Issue #477 DSB and AEMO to meet offline and agreed on an FDO for Issue 477.
- Biza to raise a ticket on energy usage data covering multiple FRMPs. DSB to table this in their discussions with AEMO.
- This was discussed in recent meeting with AEMO, Biza and big 3 retailers. AEMO presented their analysis which indicated the scenario accounted for less than 1%. Retailers have taken action to conduct analysis on their own data. Pending outcome, ticket may be required.
InfoSec
- DSB (In Progress) Issue #435 DSB will follow up with the CDR Rules team and the OAIC regarding privacy considerations with sharing a second-party's details under the primary consumer's consent
- DSB (In Progress) Issue #458 DSB to include examples to describe the transition to FAPI 1.0
- DSB As part of the grooming process for MI11, DSB will propose on what can be included in the MI to address Issue 418 due to limited capacity.
- DSB to update Issue 418: CDR Data Holders outbound connection whitelisting to advise it will be addressed in DP245.
- prioritise Issue 500 for discussion on 25/05/2022
- DSB to update Issue 479 with explanation on dependency of JARM Specification to elicit feedback from the community for further discussion.
- Prioritise Issue 489 for discussion on 25/05/2022.
Register
- ACCC Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
- ACCC to share the details of their plan to support Issue 481.
- INDUSTRY to provide feedback to indicate when data holders with multiple sectors will need to be represented in the Register for Issue 481.
- DSB to have internal discussions to confirm DP229 covers the original concerns raised in Issue 427. Any subsequent changes to the register can be covered in DP229 and managed accordingly.
Register / DCR
- DSB to stage the change for Issue 491 and consider a patch release.
High Level Standards
- DSB to update Issue 411 with details of options, preferencing Option 1.
- Prioritise Issue 494 for discussion on 25/05/2022.
Admin APIs
- Prioritise Issue 492 for discussion on 25/05/2022.
Banking/CX
- DSB to remove 470 from MI11
Other
- DSB/ACCC: DSB to work with ACCC to explore opportunities to reconcile actions raised during the Maintenance Iteration.
- ACCC to provide feedback to the community on what their release schedule will look like.
Release plan
- Decision Proposal 237 for MI 10 was approved by the Chair on 12 May 2022.
- V1.17.0 of the standards is now published and live.
Open / Active Decision Proposals
The following decision proposals are open for community feedback
| DP # | Closing date | DP |
|---|---|---|
| 229 | Placeholder | Decision Proposal 229 - CDR Participant Representation |
| 240 | 27 May 2022 | Decision Proposal 240 - ADR Metrics |
| 245 | 27 May 2022 | Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation |
| 248 | No closing date | Noting Paper 248 - Energy PRD |
Future Plan
Review of Q1 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1
Iteration 11 Issues
All open change requests can be found here: Standards Maintenance Issues.
The standards maintenance backlog can be found here: Data Standards Maintenance
Iteration 11 Progress
The following change requests are proposed for this iteration.
CRs under consultation
Closed CRs
| Issue # | Sector | Change Request | Outcome |
|---|---|---|---|
| Issue 78 | High Level Standards | HTTP Header to be returned in the case where the request is not entirely well formed and a large page size is requested | Close issue - No change |
CRs for discussion
InfoSec
#458 FAPI 1.0 Non Normative Examples
- Discuss OIDD and SSA changes
- Discuss sequence diagram
Register
#480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
- Discuss problem space and establish priority
#484 1.13.0 Appears to have introduced new SSA error behaviours
- Discuss problem space and establish priority
- Establish the priority of having a technical control considering other controls
- Describe the cost, benefit and impact on stakeholders, of moving the obligation date
Energy
#471 Modify Energy Plans structure to allow Time of Use based Controlled Load rates
- Discuss problem space/feedback received
#477 Secondary Data Holder Planned Outages and Status
- AEMO must host publicly available 'Get Status' and 'Get Outages' endpoints for secondary data. There is general agreement on this position which should occur at a yet to be determined FDO.
- Retailers should/must expose AEMO (and potentially AER) outages and status by some mechanism.
- Discuss the inclusion of AER status and outage endpoints and the latency concerns brought up in CR feedback.
#515 Clarity around GET Metrics for AER, DELWP and AEMO
- Discuss problem space
MI11 Holistic Feedback
#511 Iteration 11 Holistic Feedback
- Update on contributions to date
Any Other Business
Meeting Minutes
Notes
Progress on Outstanding Actions
Energy
- DSB/AEMO (In Progress) meet offline to agree on an FDO for Issue #477.
- Retailers to raise a ticket on energy usage data covering multiple FRMPs. DSB to table this in their discussions with AEMO.
- Action remains open, analysis continues, when complete a decision can be made on the FDO.
InfoSec
- DSB (In Progress) Issue #435 DSB will follow up with the CDR Rules team and the OAIC regarding privacy considerations with sharing a second-party's details under the primary consumer's consent
- Initial guidance from the Treasury rules team indicates this would not be permitted within the rules for individual users. An official response from Treasury will be posted when it's available.
- DSB (In Progress) Issue #458 DSB to include examples to describe the transition to FAPI 1.0
- See CRs for discussion section in these minutes for further details.
- DSB As part of the grooming process for MI11, DSB will propose on what can be included in the MI to address Issue #418 due to limited capacity.
- Will not be addressed in MI11, refer to DP245
- DSB to update Issue #418: CDR Data Holders outbound connection whitelisting to advise it will be addressed in DP245.
- prioritise Issue 500 for discussion on 25/05/2022
- See CRs for discussion section in these minutes for further details.
- DSB to update Issue 479 with explanation on dependency of JARM Specification to elicit feedback from the community for further discussion.
- Issue has been updated with outcome of last call, no response from community received, will continue to monitor for feedback to progress in this MI.
- DSB to prioritise Issue 489 for discussion on 25/05/2022.
- Has been incorporated into Issue #511 and will be discussed in that Agenda item.
Register
- ACCC Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
- Issue has been closed as it was resolved in MI10, however the operational and testing aspects of that issue fall outside DSBs remit.
- ACCC reiterated CTS is operating as expected as its designed to be stateless so that tests can be run in any order where each scenario complies with the standards. CTS does not seek to test the entire CDR solution for an ADR or DH, it's focus is on an explicit set of scenarios outlined in the technical guidelines.
- ACCC to share the details of their plan to support Issue #481.
- ACCC has commenced analysis to validate register behaviour as it doesn't believe it behaves in the way the ticket calls out.
- Prioritise Issue #481 for discussion on 8/06/2022.
- INDUSTRY to provide feedback to indicate when data holders with multiple sectors will need to be represented in the Register for Issue #481.
- DSB to have internal discussions to confirm DP229 covers the original concerns raised in Issue #427. Any subsequent changes to the register can be covered in DP229 and managed accordingly.
- DSB CX has posted comments to confirm the way in which topics raised in the issue will be addressed in DP229.
- The issue will not be included in this MI, however it will remain open until the DP reaches maturity when it will be reassessed.
Register / DCR
- DSB (In progress) to stage the change for Issue #491 and consider a patch release.
- Changes to text will be proposed and issue will be prioritised for discussion on 8/06/2022.
High Level Standards
- DSB to update Issue #411 with details of options, preferencing Option 1.
- Ticket has been updated.
- DSB to prioritise Issue #494 for discussion on 25/05/2022.
- Has been incorporated into Issue #511
Admin APIs
- DSB to prioritise Issue 492 for discussion on 25/05/2022.
- Has been incorporated into Issue #511
Banking/CX
- DSB to remove 470 from MI11
Other
- DSB/ACCC: DSB to work with ACCC to explore opportunities to reconcile actions raised during the Maintenance Iteration.
- No progress
- ACCC to provide feedback to the community on what their release schedule will look like.
- In progress, no update available.
CRs for discussion
InfoSec
#458 FAPI 1.0 Non Normative Examples
- Discussed OIDD, DCR and SSA changes.
- Discussed sequence diagram end to end.
- Some participants expressed that PAR no longer requires
scopeandclient_idto be presented outside the request object - DSB to confirm through review of upstream specs
- If correct, agreed to remove these claims outside the request object in non normative examples to avoid implying to implementers they should be present
- Discussed OIDD parameter requirements
- Discussed a general preference to minimise statements in the CDS InfoSec profile where they are already covered by the upstream FAPI specs
- No changes identified in the SSA
- Changes to the DCR API request bodies are required (new JARM claims)
- Changes to the OIDD section are required to advertise PKCE and JARM support
- Discussed that JARM encryption for the token response was not desirable. Whilst it is part of the JARM spec, there was support to constrain the JARM spec and exclude encryption. This would simplify the client implementations considerably
- DSB to raise a change request and stage a proof of concept minimising the OpenID Provider Configuration End Point section to strip out parameters already required by upstream specs so that the CDS doesn't redundantly repeat normative references.
- CBA to raise a change request to drop encryption for the JARM token response
Register
#480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
- Contention regarding the way CDR Federation has been interpreted and implemented.
- DSB acknowledges that while Data Recipient (v1.0.0) and later Data Recipient Software Product (v1.13.0) are described as the OIDC Relying Party (Client) it's clear it has been misinterpreted causing confusion and inconsistency in implementations throughout the ecosystem.
- The scenarios, raised in the MI call that need to be considered, include:
- Sponsored ADRs and their Sponsors - should sponsored ADRs be mandated to host a unique domain?
- ADRs with a stable of software products that offer complementary services to their consumers - should these software products be permitted to share data?
- Acquisitions and mergers - should consents be transferrable when a domain changes?
- Rebranding - should consents and other identifiers persist when an entity changes its name?
- Aggregators and Outsourced Service Provider (OSP) arrangements - should consents and other identifiers persist when an ADR changes their OSP?
- DSB clarified the intention of introducing ID Permanence Rules was to prevent CDR IDs from being used as a unique identifier for unintended purposes in the way that other unique identifiers, like Tax File Numbers, have been appropriated.
- The article on Data Holder sector_identifier_uri Support has been updated to refer to this MI and issue to ensure it is not relied on at this time.
- DSB will explore CTS behaviour and previous guidance provided to understand the scenarios where a unique PPID across various software products might apply.
- DSB to determine whether this issue might be better suited to a Decision Proposal and advise accordingly.
#484 1.13.0 Appears to have introduced new SSA error behaviours
- This item calls out an SSA change management weak point that has not yet been addressed, however it has been incorporated into DP245 .
- DSB to post early analysis on the issue to determine whether its covered in DP245 or whether there is further work outside of the Decision Proposal.
- DSB to prioritise for discussion on 8/06/2022
- DSB to prioritise for discussion on 8/06/2022
Energy
#472 Modify Energy Plans structure to allow Time of Use based Controlled Load rates
- This CR covers four specific topics:
-
The proposed time of use type for controlled load does not currently cater for Solar Sponge:
- This can be addressed by adding "SOLAR_SPONGE" to the list of type ENUM values.
- Feedback is welcome on any other values that would need to be included.
-
Controlled loads that have non-specific time of use description such as "Generally available for a 6 hours period between 10pm and 7am."
- Feedback from AEMO stated that such scenarios imply the retailers are not aware of the specific time of controlled load application as this is determined by the distributor. The time can vary daily within defined bounds. In the above example a consumer would get 6 hours of controlled load usage anytime between 10pm and 7am.
- The DSB will consider how to represent this in the standards.
- Further feedback from other retailers is welcome.
- DSB to discuss
Solar Sponge requirementscontrolled loads that have non-specific time of use description with EME and Red Energy.
-
Stepped solar feed in tariffs:
- Stepped charges that are applied based on fixed usage/export amount (e.g. x cents for first 5kWh/day, y cents for the remainder)
- Example - https://www.energymadeeasy.gov.au/plan?id=RED207686MRE4&postcode=2500
- DSB will raise a CR to address stepped solar feed in tariffs separately.
-
Standardised representation time in EnergyPlanDetail schema and alignment of ENUM value for days across energy standards:
- Both of these issues have been raised as separate CRs (linked below), both will be included in MI11 for consultation
- CR#505 for time representation
- CR#502 for standardising ENUM values for days in energy standards
#515 Clarity around GET Metrics for AER, DELWP and AEMO
- ACCC, Treasury and DSB discussion has clarified there is no need for Government entities to provide Get Metrics APIs. This has resulted in the Standards being updated via this issue, due to the relative ease of editing, rather than making a change to the Rules.
- Concerns this decision would make it difficult to resolve disputes were raised and have been articulated in this comment.
Other Business
Usage Size for Get Usage Shared Responsibility API payloads
- Request to consider Issue #514 raised by AEMO to explore options to reduce payload size and increase performance, in this MI.
- DSB to prioritise Issue #514 in the next meeting.
Request to prioritise Energy issues in the MI
- Participants have requested prioritising energy specific CRs in the MI calls given the fast approaching energy deadline.
- DSB to assess and re-prioritise energy items that are more important for go-live and also consider the need to schedule an out of session energy specific MI call to resolve items required before Go Live.
New Actions
InfoSec
- DSB to confirm PAR requirement for
scopeandclient_idoutside the request object through review of upstream specs. Issue #458 - DSB to raise a change request and stage a proof of concept minimising the OpenID Provider Configuration End Point section to strip out parameters already required by upstream specs so that the CDS doesn't redundantly repeat normative references. Issue #458
- CBA to raise a change request to drop encryption for the JARM token response
Register
- DSB to determine whether Issue #480 might be better suited to a Decision Proposal and advise accordingly.
- DSB to post early analysis on the issue to determine whether its covered in DP245 or whether there is further work outside of the Decision Proposal.
- DSB to prioritise Issue #486 for discussion on 8/06/2022
- DSB to prioritise Issue #507 for discussion on 8/06/2022
Energy
- DSB to discuss
Solar Sponge requirementscontrolled loads that have non-specific time of use description with EME and Red Energy.Issue #472. - DSB will raise a CR to address stepped solar feed in tariffs separate to Issue #472.
- DSB to prioritise Issue #514 for discussion on 8/06/2022
- DSB to assess and re-prioritise energy items that are more important for go-live and also consider the need to schedule an out of session energy specific MI call to resolve items required before Go Live.
Next Steps
DSB to consider the need for an out of session meeting for Energy and advise community at the earliest convenience.
Progress actions in preparation for Maintenance Iteration Meeting on 8 June 2022.