DSB Maintenance Iteration 11: Agenda & Meeting Notes (8 June 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki
Date and time: 08/06/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 fourth 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
- Update on Energy specific iteration candidates for MI11 (to be discussed during Energy specific MI call on 14th of June)
- CRs for discussion
Outstanding Actions
Energy
- DSB/AEMO Issue #477 DSB and AEMO to meet offline and agreed 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.
- 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.
- 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.
- Issue # 520 raised.
- 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.
- An additional meeting has been scheduled to discuss Energy CRs on Tuesday 14/06/2022, the list of CRs to be discussed in captured in CRs under consultation table.
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 to confirm PAR requirement for
scopeandclient_idoutside the request object through review of upstream specs. Issue #458 :bulb: - 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 :bulb:
- CBA to raise a change request to drop encryption for the JARM token response. Issue #458 :bulb:
Register
- ACCC to share the details of their plan to support Issue 481. :bulb:
- INDUSTRY to provide feedback to indicate when data holders with multiple sectors will need to be represented in the Register for Issue 481. :bulb:
- DSB to determine whether Issue #480 might be better suited to a Decision Proposal and advise accordingly. :bulb:
- 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. :bulb:
- DSB to prioritise Issue #486 for discussion on 8/06/2022.
- DSB to prioritise Issue #507 for discussion on 8/06/2022.
Register / DCR
- DSB to stage the change for Issue 491 and consider a patch release.
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
CX
#485 Common Data Clusters altered for Energy Data Language
- Consult on scope and timing required for any proposed changes to customer data language for the energy sector.
InfoSec
(NEW) Transition of required parameters in the CDR Arrangement JWT
- General discussion
#458 FAPI 1.0 Non Normative Examples
- Discuss OIDD and SSA changes
- Discuss sequence diagram
Register
- Describe the cost, benefit and impact on stakeholders, of moving the obligation date
- Establish the priority of having a technical control considering other controls
#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 priority
#481 Provide timeline of when multiple sectors per data holder brand will be supported
- Establish priority
Energy
The following Energy issues will be discussed in today's call if time permits. Alternatively they will be covered in the Energy specific MI call on the 14th of June, along with the additional Energy issues that have been added to the CRs under consultation table.
#505 Representation of time within EnergyPlanDetail Schema
- Recommendation to update the following fields to TimeString format
timeOfUseRates.timeOfUse.startTimetimeOfUseRates.timeOfUse.endTimedemandCharges.startTimedemandCharges.endTime
#502 Review ENUM values for representation of days in Energy Standards
- Discuss options presented in comment
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 Issue #477 DSB and AEMO to meet offline and agreed on an FDO for
- Ongoing discussion, this is one of the CRs we've reprioritised, refer to CRs under consultation.
- Retailers to raise a ticket on energy usage data covering multiple FRMPs. DSB to table this in their discussions with AEMO.
- Still outstanding, outcome of analysis will determine whether there is a need to raise a separate CR.
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.
- This CR has been removed from today's agenda as we're waiting on feedback from the community, particularly in relation to options that would result in moving away from the current solution where all participants will be impacted.
- Anticipating further feedback and confirmation from OAIC, early advice suggests it's unlikely details of the secondary consumer would be sharable.
- Another related issue to note, dependent on OAIC advice, is the request to indicate joint or complex accounts.
- DSB to confirm PAR requirement for
scopeandclient_idoutside the request object through review of upstream specs. Issue #458 - See CRs for Discussion in Meeting Minutes for details.
- 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
- See CRs for Discussion in Meeting Minutes for details.
- CBA to raise a change request to drop encryption for the JARM token response. Issue #458
- See CRs for Discussion in Meeting Minutes for details.
Register
All of these actions were addressed and outcomes captured in CRs for Discussion.
- 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 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.
Register / DCR
- DSB to stage the change for Issue 491 and consider a patch release.
- Still pending, if we consider a patch release it will be a candidate otherwise it will included in the next major release.
Other
- DSB/ACCC: DSB to work with ACCC to explore opportunities to reconcile actions raised during the Maintenance Iteration.
- The intent of the Agenda and Minutes is to track issues raised however the onus is on the stakeholder to provide context and manage actions through to resolution. There is a requirement to for appropriate context to be captured to ensure each action is meaningful.
- ACCC to provide feedback to the community on what their release schedule will look like.
- This action is more appropriate to manage in Thursday's Implementation Calls as an update or notification to the community. We are still working out how that would look and will update accordingly.
CRs for discussion
CX
#485 Common Data Clusters altered for Energy Data Language
- Background: CX standards treat customer as sector specific which is consistent with the rules, however the Standards treat customer data the same across sectors. In discussion with Treasury we have reached an agreement to pursue standardising customer data in the Rules.
- Progressing this change would result in some attributes that are currently mandatory for Banking, i.e. organisation, to be made optional so the same schema can apply to Banking, Energy and all forthcoming sectors.
- The CDR-CX-Stream comment lists three options, the DSB is looking for community feedback on preferences and any concerns the options raise.
InfoSec
(NEW) #521 Transition of required parameters in the CDR Arrangement JWT
- Discussed urgency and the intent to deal with this change before the FDOs of July 31st.
- Three options were presented.
- ADRs indicated that they were amenable to supporting the changes and the effort would be low to accommodate mixed-mode JWT validation before phasing in the final state.
#458 FAPI 1.0 Non Normative Examples
- Discussed raising a CR to deal with OIDD clean-up.
- Sequence diagrams have been updated with outcomes of the previous call.
- Non-normative examples being updated accordingly.
- Further considerations:
- A participant asked whether the
client_descriptionin the SSA needs to support special characters. This has been confirmed that it is a UTF-8 string and therefore needs to support Unicode characters. - A participant also asked whether legal entity and organisation id would ever change. The DSB confirmed that these could where mergers, acquisitions or splits can change legal entities for the holders of data and consumers of data owning software products.
- A participant asked whether the
Register
- Considered along with #486, see below.
- Issue was carried over from MI10 as concern that new scopes for energy would not be supported resulting in DHs returning an error during DCR. Technical solutions were considered and Issue 488) was raised to provide clarity that DHs shouldn't fail DCR requests if unsupported scopes are present. This issue was resolved in MI10.
- Issue 507 (listed above) was raised to address the potential for the risk to remain at go live for Energy and to set an FDO earlier than 15 November to enable the
ACCC Technical Operations teams to identify and resolve any incidents that may occur in the months prior to that dateACCC Compliance and Enforcement teams to identify any non-compliant Data Holders and implement rectification plans prior to when they could potentially disrupt the CDR ecosystem. - The challenge is identifying Data Recipients who will either create or update a registration with a Banking DH in that window.
- No ADRs on the call volunteered an opinion.
- Biza confirmed unknown scopes are ignored in their Holder as a Service platform so can't comment on the cost to uplift, although acknowledged it sounds hard to change in a few months, and is aware of DHs that do reject DCR with unknown scopes.
- Next Steps have been summarised in this CDR-API-Stream comment on GitHub
- DSB to post comments on #507, see comment)
#480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
- CDR-API-Stream comments on this Issue were called out for clarity.
- Intention of
sector_identifier_uriwas to create flexibility, however there are obvious use cases that do not apply to the CDR. - Question is do we constrain the CDR to prevent accidental deviation from what the standards are intended to achieve?
- DSC encourages the community to put some thought into this issue to ask questions or post comments on the issue.
#484 1.13.0 Appears to have introduced new SSA error behaviours
Any fields the data holder brand does not support are not persisted. However, registration responses must conform to the DCR API specification
The change in language was not intended to change the interpretation of the Standards.
However, this concern raises the following question. Should the registration process enforce the downstream technical or business requirements of the CDR?
Using the sector_identifier_uri example, if a data holder does not support this field, after the obligation date has passed, the creation of a registration would still occur but the sector_identifier_uri would return unpopulated. If the data recipient requires the sector_identifier_uri, this registration does not facilitate the Standards, however, if sector_identifier_uri support is not required, data sharing can continue as normal.
There are various reasons that a data holder may not have met their obligation. They may be late, the ACCC can provide exemptions. There is benefit in having flexibility in the process if obligation dates are not met.
It’s also worth considering that if an older registration already exists but is not updated when there is the addition of the sector_identifier_uri support, the data recipient will not benefit from the sector_identifier_uri but the data holder will continue to share consumer data. Therefore, new registrations are impacted more significantly than current registrations.
If a data holder is to return an error on receipt of a registration request with fields they do not support, the data recipient will have no opportunity to request consumer data. The benefit of this approach is that any consequences of the lack of support are less likely to occur.
- ACCCs Accreditation and Legal teams require more time to analyse the impacts on rules.
- ACCC to advise on whether MI12 is an appropriate iteration to resolve this issue.
#481 Provide timeline of when multiple sectors per data holder brand will be supported
- ACCC is keen to hear comments from industry on this issue as per CDR-API-Stream comments although is cognisant of the potential for commercial sensitivities.
- If this issue is to be deferred from this iteration, the implications on the ecosystem need to be acknowledged.
- ACCC to advise on what iteration this issue should be resolved
Energy
The following Energy issues will be discussed in today's call if time permits. Alternatively they will be covered in the Energy specific MI call on the 14th of June, along with the additional Energy issues that have been added to the CRs under consultation table.
#505 Representation of time within EnergyPlanDetail Schema
- If no comments have been received by the end of the iteration, our assumption is the recommendation to update the nominated fields to TimeString format will be put to the chair for approval.
#502 Review ENUM values for representation of days in Energy Standards
- Refer options presented in comment
- Proposed options were agreed to in principle with the addition of 'Public Holiday'
- DSB to update the ticket, refer comment
MI11 Holistic Feedback
#511 Iteration 11 Holistic Feedback
The following issues are being managed under #511.
-
#495 Energy - GetAgreedPaymentSchedule API - paymentFrequency)
- Concerns bill frequency is expected to be mapped payment frequency when this is not always the case, particularly when paying manually.
- The intent of the endpoint is to capture consumer preferences on how they wish to pay not all payment schedules and associated detail or arrears.
- DSB to post comments on this issue to clarify the agreement to capture method of payment but not frequency.
-
Refer 511 comment 1126687376
- Banking has accommodated digital wallet and PayPal
- DSB to update ENUM for Energy Get Agreed Payment Schedule to incorporate Digital Wallet and PayPal values.
- isTokenised documentation error, mentioned in the same comment, will be corrected
- DSB to post on the #511 thread to clarify isTokenised correction.
- Banking has accommodated digital wallet and PayPal
-
Refer 511 comment 1131001514
- This correction has been staged, you can view the commit on the Standards-Staging repository here.
New Actions
Register
- DSB to post comments on #507, see comment)
- DSC encourages the community to put some thought into issue #480 to ask questions or post comments on the issue.
- ACCC to advise on whether MI12 is an appropriate iteration to resolve issue #431.
- ACCC to advise on what iteration issue #481 should be resolved
Energy
- DSB to update the ticket, refer comment
MI11 Holistic Feedback
- DSB to post comments on this issue #495 to clarify the agreement to capture method of payment but not frequency.
- DSB to update ENUM for Energy Get Agreed Payment Schedule to incorporate Digital Wallet and PayPal values to address 511 comment 1126687376.
- DSB to post on the #511 thread to clarify isTokenised correction called out in 511 comment 1126687376.
Next Steps
Discuss remaining open CRs and finalise proposals for presentation on 22 June 2022.