DSB Maintenance Iteration 11: Agenda & Meeting Notes (29 June 2022) - ConsumerDataStandardsAustralia/standards GitHub Wiki
Date and time: 29/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 we reconvene the Approvals and Documentation call held on 22 June to close out Maintenance Iteration 11 items that were not discussed.
-
Housekeeping
Outstanding Actions
Energy
- DSB/AEMO Issue #477 DSB and AEMO to meet offline and agreed on an FDO for Issue 477.
- This action will be carried over to the next MI
- Retailers to raise a ticket on energy usage data covering multiple FRMPs. DSB to table this in their discussions with AEMO.
- This action will be carried over to the next MI
- DSB to assess if its viable to remove servicePoint from Issue #495 and keep the response as an array. :bulb:
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.
- CBA to raise a change request to drop encryption for the JARM token response. Issue #458 :bulb:
Register
- DSB to post early analysis on issue 484 to determine whether its covered in DP245 or whether there is further work outside of the Decision Proposal. :bulb:
- ACCC to advise on whether MI12 is an appropriate iteration to resolve issue #431. :bulb:
- DSB to work with ACCC on appropriateness of bringing Issue #510 in now and provide commentary on the CR. :bulb:
Register / DCR
- DSB to stage the change for Issue 491 and consider a patch release.
CX
- DSB to consider Issue #485 further and seek input from the Banking sector before finalising the recommendation on 29 June 2022. :bulb:
Other
- DSB/ACCC: DSB to work with ACCC to explore opportunities to reconcile actions raised during the Maintenance Iteration.
Release plan
- V1.17.0 of the standards is now published and live.
- MI11 change requests will be published in release 1.18.0
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 |
| 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
(Urgent) #521 Transition of required parameters in the CDR Arrangement JWT
- For discussion
Energy
- Removal of servicePointId from proposed solution.
Register
- Review proposal
- Discuss problem space and next steps
- Review Deferral
#481 Provide timeline of when multiple sectors per data holder brand will be supported
- Review Proposal
#510 Register API error codes need to be aligned with the CDS standardised error codes
- Provide updates on conversations with ACCC around the timing of this change.
#480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
- Discuss problem space and next steps
#484 1.13.0 Appears to have introduced new SSA error behaviours
- Discuss problem space and next steps
CX
#485 Common Data Clusters altered for Energy Data Language
- Consider and discuss industry feedback to confirm Option 2 can be made as an urgent change.
MI11 Holistic Feedback
#511 Iteration 11 Holistic Feedback
- Update on contributions to date
Any Other Business
Meeting Minutes
Notes
Outstanding actions
Not discussed independently of the CRs for discussion.
CRs for discussion
Energy
- DSB will adopt removal of servicePoint as requested.
- All other proposed solutions will be adopted and recommended to the Chair for approval.
#502 Review ENUM values for representation of days in Energy Standards
- Charges and rates that only apply on public holidays cannot expressed using the ENUM values, i.e. Monday to Friday excluding public holidays.
- There was a recommendation to rename BUSINESS_DAYS to WEEKDAYS. This could help address concern of BUSINESS_DAYS not excluding public holidays.
- Biza to post concerns around the introduction of new ENUM values on Issue 502
CX
#485 Common Data Clusters altered for Energy Data Language
- The DSB Chair has approved the classification of this issue as urgent.
- The DSB will adopt option 2. It is a superficial change to the standards for Banking but will require Energy DHs to adopt common language standards currently used for Banking. This will not require Energy DHs to make any more data available than they currently do.
- DSBs clarification has been posted on the issue, see comment.
InfoSec
(Urgent) #521 Transition of required parameters in the CDR Arrangement JWT
- Discussed FAPI wording alignment to allow claims to be sent outside the JWT but if they are then they must be validated to be the same as what is inside the JWT
- This would allow DHs that currently send both not to be penalised. Evidence suggests ADRs are currently supporting both being sent together
- The benefit of all Self-Signed JWT claims being included is for integrity protection
- Onus on ADRs to validate both JWT flavours at end state
- DHs may send both form-parameter and JWT.
- DHs should sent Self-Signed JWT claims in addition to the cdr_arrangement_id
- Intention with the FAPI 2.0 migration is to move towards Security Event Tokens RFC 8417
- Discussed the precedence of receiving both JWT and form parameter methods where both are not the same
- There's a desire to move the July date to November to give everyone time to uplift software.
- Requirements for the CDR Arrangement ID JWT were originally a MUST but were relaxed to a SHOULD which will remain for the November date.
- This scenario presents two different error conditions however only one error, 422, is defined. Both error conditions will be required to respond with the current error code: 422/"Invalid Consent Arrangement"
- DSB to update the proposal to incorporate the outcome of the discussion
- BIZA to advise DSB offline on behaviour of 30 Mutuals
- CBA confirm whether or not validation is occurring if both methods are present, level of effort involved to make the change if not and whether the November timeframe is achievable?
Register
- This is not intended to be an introduction of the filtering functionality as proposed in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/486#issuecomment-1089578737
- Therefore, filtering on the INDUSTRY parameter will not occur on v2 or 3 of the API,
- v2 will only return Banking authorisation scopes
- v3 will return Banking and Energy authorisation scopes.
- This change has been adopted to mitigate technical risk anticipated in the ecosystem with the introduction of the Energy sector but does not set a precedence for the way in which change will be managed into the future.
- The future state of using subsets of authorisation scopes is yet to be described, and will be earmarked as a future piece of work.
- Behaviour of API if called without an x-v value defined is not currently specified, however, currently all Register APIs default to v1.
- The standards currently don't specify the scopes that will be returned in each version and this is by design.
- A request was made to consider SSA versioning for future requirements to cater for situations such as the OpenId scope which is not required for PKCE and adding scopes to the existing set for an active sector.
- ACCC and DSB to post a response on the issue that describes default behaviour on how versioning will work.
- DSB to include v1 of Get Software Statement Assertion (SSA) in the Endpoint Version Schedule as a deprecation date has not been set for this version.
- DSB to look at SSA versioning, overlaping with the discussion on issue #484
- One benefit of bringing the compliance date forward is to enable DHs to notify the ACCC and then ADRs that unknown/unsupported scopes are not ignored via the ACCC's rectification schedule. It is important to note the intention is not to facilitate compliance actions, it is to provide a window for the change to be made before the Energy go-live date and resolve any technical issues that may arise.
- There has been a lack of data holder and data recipient feedback on the movement from the November date
- Given the outcome on #486 above, there is a lack of understanding on the need for this change as there is no detail in the justifications published on GitHub
- ACCC requesting input from industry on this issue.
- ACCC to post a clarification on the need for the FDO to be brought forward if the purpose is not to enable enforcement action and to confirm dates the change will take effect.
- ACCC advises that the combination of revoked and invalid statuses isn't a valid state. To clarify, the active to inactive to removed flow is applicable in the case of a suspension, the ADR may
- have their suspension lifted
- the status would be reset to Active
- opt to Surrender
- the status would flow from Inactive to Removed
- be revoked
- the status would flow from Inactive to Removed
- have their suspension lifted
- ACCC to provide commentary on the issue that the combination of statuses is not valid and to confirm there will be no unintended consequence resulting from of the proposed documentation change.
- DSB to update the proposal for this issue. If the Revoked Inactive combination is not a valid state, the proposed change is no longer relevant.
#481 Provide timeline of when multiple sectors per data holder brand will be supported
- While the ACCC is not aware of any Data Holder brands that currently participate in more than one sector the current state permits multiple industries to be recorded and returned.
- A reciprocity scenario that applies in the Energy sector may be an example worth investigating.
- DSB to remove the statement "Please note that the CDR Register entity model is constrained to one industry per brand which is planned to be relaxed in the future." from ResponseDataHoldersBrandSummaryList
#510 Register API error codes need to be aligned with the CDS standardised error codes
- Intention is to clarify ambiguity in the standards because two references conflict on which error will apply.
- Feedback provided that there is a lot of change in the MI and there would be benefit of prioritisation as this change is not high priority
- DSB to discuss the change set with the team in order to consider whether any change should be adopted in this MI. If they cannot be adopted they will be moved to a later MI when new Register versions can incorporate the change.
#480 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
- Good feedback has been received on this issue from the community
- A rules clarification has been provided that there are valid scenarios for consumer data to be shared between software products of the same ADR, however this does not apply to sponsors and affiliates, and principles and CDR representatives
- How identifiers are currently being used and the usage of the PPID model needs further investigation. Due to the complexity and remaining analysis, this issue will not be resolved in MI11.
- DSB to investigate original proposals in Issue #427
- DSB to determine how to continue this piece of work post MI11
#484 1.13.0 Appears to have introduced new SSA error behaviours
- Discussion on this topic has centred around the change of
sector_identifier_urihowever this issue should consider how SSA change management is handled. - Issue 443 looks at how to deprecate the revocation_uri and the complexity of SSA change management is highlighted here.
- DSB to consider withdrawing this from MI11 and to address this issue, along with issue 443, as a dedicated decision proposal.
MI11 Holistic Feedback
#511 Iteration 11 Holistic Feedback
- Not discussed
Any Other Business
None
New Actions
**Energy **
- Biza to post concerns around the introduction of new ENUM values on Issue 502
InfoSec
- DSB to update the proposal on #521 to incorporate the outcome of the discussion
- BIZA to advise DSB offline on behaviour of 30 Mutuals regarding #521
- CBA confirm whether or not validation is occurring if both methods are present, level of effort involved to make the change if not and whether the November timeframe is achievable with regard to #521?
Register
- ACCC and DSB to post a response on issue #486 that describes default behaviour on how versioning will work.
- DSB to include v1 of Get Software Statement Assertion (SSA) in the Endpoint Version Schedule as a deprecation date has not been set for this version to facilitate changes associated to #486.
- DSB to look at SSA versioning in issue #486, overlapping with the discussion on issue #484.
- ACCC requesting input from industry on issue #507.
- ACCC to post a clarification on the need for the FDO for issue #507 to be brought forward if the purpose is not to enable enforcement action and to confirm dates the change will take effect.
- ACCC to provide commentary on the issue #431 that the combination of statuses is not valid and to confirm there will be no unintended consequence resulting from of the proposed documentation change.
- DSB to update the proposal for issue #431. If the Revoked Inactive combination is not a valid state, the proposed change is no longer relevant.
- DSB to remove the statement "Please note that the CDR Register entity model is constrained to one industry per brand which is planned to be relaxed in the future." from ResponseDataHoldersBrandSummaryList to address issue #481
- DSB to discuss the change set with the team in order to consider whether any change to address issue #510 should be adopted in this MI. If they cannot be adopted they will be moved to a later MI when new Register versions can incorporate the change.
- DSB to investigate original proposals in Issue #427 to consider how to progress issue #480
- DSB to determine how to continue this issue #480 post MI11
- DSB to consider withdrawing issue #484 from MI11 and to address this issue, along with issue 443, as a dedicated decision proposal.
Next Steps
Stage the changes for community review, write DP249 and seek approval from the DSB Chair.