DSB Maintenance Iteration 10: Agenda & Meeting Notes (13 April 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki

image

Date and time: 13/04/2022, 2:00pm – 4:00pm AEDT

Location: WebEx

Dial-in details:

Chair: Ivan Hosgood, DSB

Maintenance overview: Further information

Maintenance project board: See here

Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 237

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.

Caretaker Convention

"During the caretaker period, the business of government continues and ordinary matters of administration still need to be addressed."

Refer Section 2.4 of the Guidance on Caretaker Conventions.

The making and amending of the non-legislative Data Standard instruments are considered an ordinary matter of administration.

Maintenance Iteration 11

Maintenance Iteration 11 is scheduled to commence on 27 April 2022. A place holder invitation has been sent and will be updated in the coming days. Publication of Decision Proposal 237 and v1.17.0 of the Standards may occur after this date, depending on timing for a decision from the DSB Chair.

Agenda

  • Introductions
  • Outstanding Actions
  • Release plan
  • Open Decision Proposals: key consultation dates
  • Iteration 10 issues
  • Any other business

Meeting notes

Introductions

This week is the sixth and final call of the 10th maintenance iteration.

The purpose of the meeting is to close out the candidates consulted on in 10th maintenance iteration.

  • Overview, purpose and intended outcomes of the meeting

Outstanding Actions

  • DSB to reach out to ADR contacts to assess priority of change for MI10 banking change requests #291 and #292.
  • NAB to perform analysis on Issue #229 Service field in the Get Transaction Details API and advise on outcome in MI10 Meeting #2.
  • Issue #439 DSB to propose solutions options to accommodate pricing models as an attribute of the charge instead of the contract.
  • Issue #472 DSB to raise new issue to assess consistent representation of ENUM values for 'days' across sectors and within energy endpoints - Link to CR
  • Issue #444 ACCC to publish a description of the new unauthenticated API on the issue and address industry requests.
  • Issue #439 DSB to draft the proposal for review and if there is no further comment from participants the change will be recommended to the Chair.
  • Issue #476 DSB to update option 2 with any feedback received and will recommend the change to the Chair.
  • Issue #476 DSB to remove "additionalValue" attribute and apply condition to "additionalInfo" attribute to be mandatory if type is "VARIABLE".
  • Issue #477 DSB will put forth the position, for comments from industry, that retailers must consume and publish AEMO outage and status at an FDO yet to be determined. If there are no objections the change will be recommended to the DSB Chair.
  • Issue #478 DSB to update proposal to specify the scenarios raised in the original CR where existing error codes will be applicable.
  • Issue #444 DSB to assess whether all consequences associated to the issue have been considered and discuss at the meeting on 13 April 2022.
  • Issue #444 DSB to add commentary on the ticket to address the relationship between statuses and DP245.
  • Issue #435 Biza/Participant to provide comments for further consideration
  • Issue #464 DSB will work through the issue to determine opportunities for improvement to address MI9 Retrospective. 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
  • Issue #458 DSB to include examples to describe the transition to FAPI 1.0
  • Issue #488 DSB to discuss internally what evidence can be presented to determine whether DHs will be non-compliant when scopes grow
  • Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
  • Issue #435 DSB to update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April.
  • Issue #458 DSB will discuss the issue of potential documentation changes to accommodate upstream changes to JARM when FAPI moves from optional to mandatory offline and update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. Considerations will need to be made on whether the Discovery Configuration Endpoint and DCR documentation should be updated to defer to the upstream standards or explicitly document the fields required to enable JARM support.
  • Issue #486 ACCC to provide feedback on the proposal and comment on the feasibility of FDO.

Release plan

  • 1.16.1 was released on the 22nd of March 2022.
  • MI 10 change requests will be published in release 1.17.0

Obligation Dates

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
203 No closing date Normative Standards Review (2021)
240 No closing date Decision Proposal 240 - ADR Metrics
245 TBD Soon to be published: Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation

Iteration 10 Issues

All open change requests can be found here: Standards Maintenance Issues.

The standards maintenance backlog can be found here: Data Standards Maintenance

Iteration 10 Progress

The following change requests are currently in the design stage for this iteration

Issue # Sector Change Request Decision Change Status Future Dated
Obligation (FD)		 Affected Schema
(if applicable)		 Affected Endpoint
(if applicable)		 Recommendation
448 Energy EnergyPlanDiscounts contains optional fields that should be conditional Change Recommended Non-breaking change 01/10/2022 EnergyPlanDiscounts Adopt the change
449 Energy EnergyPlanSolarFeedInTariff days field should be mandatory Change Recommended Non-breaking change 01/10/2022 EnergyPlanSolarFeedInTariff Adopt the change
457 Energy Energy - Get Service Point Detail register suffix should be optional Change Recommended Non-breaking change 15/11/2022 EnergyServicePointDetail Adopt the change
423 Energy Review of demand charges in energy billing transactions Change Recommended No Change Non-breaking change 15/11/2022 EnergyBillingTransaction No change required as otherCharges already allows capturing network charges, which would include demand charges for C&I customers.
438 Energy Representing adjustment transactions within the Billing Payload for C&I customers Change Recommended Non-breaking change 15/11/2022 EnergyBillingOtherTransaction Amend 'otherCharges' to include 'calculationFactors' and 'adjustments' as per this comment
439 Energy Review Pricing Model & Time Zone attributes within Account Detail Payload Change Recommended Non-breaking change 15/11/2022 Get Energy Account Detail Include an optional ‘timeZone’ attribute within EnergyPlanTariffPeriod so charge specific time zones can be provided. If absent, contract level timezone would be assumed.
472 Energy Modify Energy Plans structure to allow Time of Use based Controlled Load rates Change Recommended Non-breaking change 01/10/2022 EnergyPlanControlledLoad Amend 'controlledLoad' object to cater for time of use based rates as per this comment
476 Energy Modify Energy concessions structure to allow non-fixed (e.g. daily, monthly etc.) concessions Change Recommended Non-breaking change 15/11/2022 EnergyConcessionsResponse Amend EnergyConcessionsResponse schema to allow representation of concessions that are calculated based on variable parameters with the changes specified in this comment
477 Energy Secondary Data Holder Planned Outages and Status Change Recommended Non-breaking change TBD The following changes are recommended:
- AEMO to host publicly available 'Get Status' and 'Get Outages' endpoints for secondary data
- Retailers must consume and publish AEMO outage and status information via their own 'Get Status' and 'Get Outages' endpoints
478 Energy Energy Secondary Data Holder & Application Specific Errors Change Recommended Non-breaking change 15/11/2022 EnergyServicePointDetail Make “meters” and “register” objects in EnergyServicePointDetail optional to cater for scenarios where meter or register information for a NMI is not available. No other changes are required. Summary of scenarios can be found here
453 Register Consider an upper bound on trusting entity statuses when they go missing Change Recommended Non-breaking change N/A Specify no upper-bound and no FDO
465 Register Confirm Register API 2022 release dates Change Recommended Non-breaking change 15/11/2022 Change binding dates for new CDR Register API versions to the 15th of November 2022
498 Register New Register Authenticated APIs versions require multiple authorisation scopes Change Recommended Non-breaking change N/A Correct defect in the swagger so only the cdr-register:read scope is required for new versions of the CDR Register authenticated APIs
501 Register Register API x-v headers moving to mandatory impacts compatibility with older versions of these APIs Change Recommended Non-breaking change N/A Rollback x-v changes from mandatory to optional for new CDR Register API versions.
Also explicitly call out that the default version of the response when x-v is not provided will be the minimum supported version
452 Register Deprecation and retirement dates for CDR Register superseded endpoint versions needs to be defined Change Recommended Breaking Change 07/04/2023 N/A CDR Register APIs Deprecation and retirement dates for superceded CDR Register endpoints should follow conventions already established by the DSB.
459 Register Sector Agnostic Register APIs Not Supported No change N/A N/A N/A Its DSB's position that insufficient benefit would be obtained from this change and future improvements to the Register APIs may be impacted by collapsing these URLs. DSB recommends that this change is not to be adopted
444 Register Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API Change Recommended Non-breaking change TBD Introduce a new API dedicated to data holder brand public endpoint discovery
488 Register Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes Change Recommended Breaking change 15/11/2022 N/A Register Data Recipient oAuth Client, Update Data Recipient Registration Data Holder Brands should ignore unsupported authorisation scopes presented in the SSA for the creation and update of Client Registrations.
486 Register Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products Continue consultation through next maintenance iteration / DP N/A N/A N/A N/A This topic is complex and requires futher consultation time, or dedicated consultation through a DP
443 Register SSA definition: Deprecation of revocation_uri Change Recommended Breaking Change 15/11/2022 N/A Get Software Statement Assertion (SSA) SSA Change management will conform to the conventions already laid out in the Consumer Data Standards. Revocation_uri will be removed from the SSA definition
431 Register Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive Deferred N/A N/A N/A N/A This issue has been deferred from maintenance iteration 10 at the request of the ACCC
405 Infosec Alternative mechanisms for OTP Deferred Carry over to Maintenance Iteration 11 - note this change is impacted by Caretaker mode and cannot be consulted on until the conclusion of caretaker mode
435 Infosec Nominated representative end user for non-individual consumers Deferred Carry over to Maintenance Iteration 11 - the discussion is still ongoing and no solution has yet been agreed
482 Infosec JWT signing non-normative examples use unsupported signing algorithm Change Recommended Non-breaking change N/A N/A N/A Non-normative example update
458 InfoSec FAPI 1.0 Non Normative Examples Deferred Carry over to Maintenance Iteration 11 - the discussion is still ongoing and no solution has yet been agreed

Related Items

Issue # Sector/Domain Change Request
484 Register 1.13.0 Appears to have introduced new SSA error behaviours

Backlog change requests

The following change requests had been proposed for this iteration however there isn't enough remaining capacity to accommodate them. They will be prioritised for Maintenance Iteration 11 provided there is community support and no further issues with a higher priority emerge.

Issue # Sector/Domain Change Request
418 Register CDR Data Holders outbound connection whitelisting
480 Register 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
409 NFR Dynamic Client Registration Response Time NFR
458 InfoSec FAPI 1.0 Non Normative Examples
292 Banking Credit card balance plans and payment hierarchy: inadequate information within the CDS
291 Banking Credit card loyalty program data: significant gaps and lack of structure
462 Banking Make additional account attributes available in bulk standards-maintenance
463 Banking Account holder name(s)
470 Banking Overloading of banking language for scopes / data clusters
471 Banking Additional credit card fields standards-maintenance
475 Energy Energy - Representation of Spot price based contracts for C&I customers
456 Energy Updates required to a property and the example provided in EnergyPlanSolarFeedInTariff schema
467 Energy Missing link between Account and Plan
474 Energy Update description of energy API attributes (where applicable) to specify which rates are GST exclusive

Any other business

Next Steps

Meeting Minutes

Notes

Outcome of discussion on Outstanding Actions

  • Issue #464 DSB will work through the issue to determine opportunities for improvement to address MI9 Retrospective.
    • 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
    • For discussion in this session.
  • Issue #458 DSB to include examples to describe the transition to FAPI 1.0
    • For discussion in this session.
  • Issue #488 DSB to discuss internally what evidence can be presented to determine whether DHs will be non-compliant when scopes grow
    • For discussion in this session.
  • Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
    • Commentary on posted on the issue highlights pain points for discussion today.
  • Issue #435 DSB to update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April.
    • Update will be provided later in the agenda and relates to 485.
  • Issue #458 DSB will discuss the issue of potential documentation changes to accommodate upstream changes to JARM when FAPI moves from optional to mandatory offline and update the community on progress of this issue in the next maintenance iteration meeting on the 13th of April. Considerations will need to be made on whether the Discovery Configuration Endpoint and DCR documentation should be updated to defer to the upstream standards or explicitly document the fields required to enable JARM support.
    • For discussion in this session.
  • Issue #486 ACCC to provide feedback on the proposal and comment on the feasibility of FDO.
    • For discussion in this session.

Open / Active Decision Proposals

  • DSB to correct reference to Decision Proposal 245; it has now been published

MI10 Candidates

Energy

Register

  • Issue 444 - Add an unauthenticated GetDataHolderBrands endpoint exposed as a public API

    • Two questions to answer, 1. does the proposed end state meet the industry needs? and 2. how will ACCC's release timeframe influence the need for an intermediary solution?
    • Comments from Stay or Go: agreement that the API looks good but there is concern around timing and the optionality of brandId.
    • The API should've been available from Day 1 and industry has had a couple of years without it, so getting a solution out there fairly quickly should be considered.
    • Preference would be to operate with interim v1 optional brandId which is then made mandatory in v2 with timeframes of 1 month for v1 and 6 months for v2.
    • Challenge for industry is not having full visibility of all brands in the market place and it would be useful to see that list grow over time and identify uniqueness with brand name changes etc.
    • Unable to understand why brandId is so complex to generate and why an interim id couldn't be used?
    • ACCC couldn't attend today's meeting so is unable to provide advice on delivery timeframes. However, the DSB understands ACCCs concern is the ability to generate a brandId before a Data Holder on-boards to commence consumer data sharing obligations.
    • In principle agreement that an interim ID would be useful acknowledging it cannot be made available across other APIs and would be removed once brandId is allocated.
    • DSB to work with ACCC to resolve API design and determine whether it can be included in this MI or deferred to MI11. Register 444
    • The outcome of this action will be documented against the issue and through the Decision Proposal

  • Issue 453 - Consider an upper bound on trusting entity statuses when they go missing

    • Proposal seeks to explicitly state no upper bound. No FDO will be provided as this is a non-breaking standards change
    • Continued concern with regard to non-standard behaviour of CTS and difficulty for participants to meet the Registrars requirements while remaining compliant. Not having visibility on when CTS will address this contributes to this difficulty
    • There is an outstanding action on ACCC that covers this issue which is separate from the change proposed in this issue.
    • DSB proposes this change is recommended

  • Issue 465 - Confirm Register API 2022 release dates

    • This issue has generated two new issues 498 and 501 addressed separately.
    • This proposal aligns release dates with Energy.
    • Concern regarding delivery timeframes if the register doesn't implement with sufficient time to test which has impacts on a DHs ability to meet the FDO. This is problematic and is compounded with the recent release of v3 of GetDataRecipients which is not compliant with the standards.
    • DSB will take this offline to get advice from the team on how this situation should be managed.
    • DSB proposes this change is recommended

  • Issue 498 - New Register Authenticated APIs versions require multiple authorisation scopes

    • This issue has been raised to address the documentation defect of unintended scope unions idlentified in Issue 465.
    • DSB proposes this change is recommended

  • Issue 501 - Register API x-v headers moving to mandatory impacts compatibility with older versions of these APIs

    • This issue has been raised to address the unintended consequence of x-v headers identified in Issue 465.
    • DSBs intention was to update the documentation to explicitly state how versions should be interpreted as the goal to align register API headers and payloads with the standards can't be achieved with two versions in play.
    • Reports that register is currently returning x-v=1 for getDataRecipients, minimum supported version would result in accreditation id not being returned which is mandatory to present in the consent flow. Minimum supported version would result in non-compliance.
    • Default version should previously active version, which would be v2, because it supports compliance.
    • Register hasn't retired v1 yet.
    • DSB to work with ACCC to determine the best course of action to resolve correct versions for each of the Register APIs Issue 501
    • DSB proposes this change is recommended

  • Issue 452 - Deprecation and retirement dates for CDR Register superseded endpoint versions needs to be defined

    • DSB proposes this change is recommended

  • Issue 459 - Sector Agnostic Register APIs

    • Feedback did not describe sufficient value to the ecosystem to warrant this change.
    • Clarification on behaviour to ensure banking is not impacted is being driven through Issue 486
    • The DSB proposes that this change is not adopted.

  • Issue 486 - Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products

    • Feedback provided does not help to determine whether this change is necessary and addresses ecosystem risk. Further analysis is required with ACCC to consider the operational impact. There is insufficient time this iteration to complete this work.
    • Deferred to MI11.

  • Issue 488 - Data holder behaviour clarification required when receiving registrations with unsupported authorisation scopes

    • Expectations on data holder have been proposed and change recommended
    • ACCC's request to change the obligation dates to September 2022 presents complexity as this represents < 6 months notice to data holders.
      • DSB to update proposal considering whether the change of the obligation date will be considered.
    • DSB proposes this change is recommended

  • Issue 443 - SSA definition: Deprecation of revocation_uri

    • DSB proposes this change is recommended

  • Issue 431 - Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive

    • Deferred.

Information Security

  • Issue 405 - Alternative mechanisms for OTP

    • Dependency on CX research to test consumer behaviour assumptions; this is underway.
    • Cross over with FAPI 2.0 where standards can be leveraged.
    • Deferred.

  • Issue 435 - Nominated representative end user for non-individual consumers

    • An overview of DSBs comments on this issue generated discussion and consensus on the need to define agent roles for individuals.
    • Deferred.

  • Issue 458 - FAPI 1.0 Non Normative Examples

    • DSB encourages the community to review the sequence diagrams and provide feedback in order for this issue to be progressed.
    • Work continues to build out the diagrams for other flows such as OIDC hybrid without PDCE and JARM. The diagrams and related changes will staged to enable review.
    • Deferred.

  • Profile scope

    • Discussed the need for a change to be made this iteration to correct a documentation error.
    • The description in the Authorisation Scopes column regarding Data Language Standards for Contact Details (Profile Scopes) incorrectly imply that the profile scope can be used to request these contact detail claims. These claims, although standard OIDC claims, are not defined within the profile scope.
    • The intention is that Data Holders may support these claims if they desire and ADRs must request them as individually named claims, not as part of the profile scope
    • The DSB will create a new change request to address this

New Actions

  • DSB to correct reference to Decision Proposal 245; it has now been published
  • Issue 444 DSB to work with ACCC to resolve API design and determine whether it can be included in this MI or deferred to MI11.
  • Issue 465 DSB will take this offline to get advice from the team on how this situation should be managed.
  • Issue 501 DSB to work with ACCC to determine the best course of action to resolve correct versions for each of the Register APIs Issue 501
  • Issue 488 DSB to update proposal considering whether the change of the obligation date will be considered.
  • Issue 472 DSB to raise a change request to consider standardising time in EnergyPlanContract schema.
  • Issue 476 DSB to correct RateString on Issue 476.
  • Issue 477 DSB and AEMO to meet offline and agreed on an FDO for Issue 477.
  • Issue 478 DSB to raise a change request to help define any new specific error codes required for dealing with issues in data received by DH from SDH.
  • DSB to add a new change request for Profile scope data language fix. See https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/504

Any other business

None

Next Steps

  • Decision Proposal DP237 will be drafted to reflect the outcome of this Maintenance Iteration and submitted to the Chair for approval. The changes will be staged and released as V1.17.0.
⚠️ **GitHub.com Fallback** ⚠️