Date and time: 11/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

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.

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.

• Introductions
• Outstanding Actions
• Release plan
• Open Decision Proposals: key consultation dates
• Future Plan
• Iteration 11 iteration candidate review
• CRs for discussion
• Any other business
• Next Steps

Meeting notes

• Meeting Notes
• Next steps

This week is the second call of the 11th maintenance iteration.

The purpose of the meeting is to consult with the community on candidates identified for the 11th maintenance iteration.

• Housekeeping
• Agree and finalise iteration candidates for MI11
• Discuss first set of proposed CRs

• 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 and DSB to table this in their discussions with AEMO.
• DSB to update Noting Paper 248 to clarify PRD hosting obligations.

• 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.

• ACCC Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
• DSB to raise an additional CR to address the FDO request by ACCC in MI 11 Issue 488.
• DSB to break this CR into two topics and invite community to comment to help drive priority Issue 427.

• 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.

• Decision Proposal 237 for MI 10 is with the Data Standards Advisory Committee for review.
• V1.17.0 Will be published once DP237 has been approved by the Chair.

The following decision proposals are open for community feedback

Review of Q1 and new changes: https://github.com/ConsumerDataStandardsAustralia/future-plan/projects/1

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

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

The following change requests are proposed for this iteration.

#78: HTTP Header to be returned in the case where the request is not entirely well formed and a large page size is requested

• Issue has been closed
• Enhanced Error Handling (see Error Codes in the Data Standards) defines error codes for both errors presented in the original CR.

#172: Validation of client_id parameter in client authentication requests

• Proposed action: close with no change.
• client_id is currently REQUIRED in the client assertion JWT but not required in the upstream FAPI standards
• if client_id is present in the JWT then the upstream standards state it MUST be validated.
• This would imply default behaviour is for all DHs to validate the client_id is correct and that ADRs MUST supply it.

#200: Documentation defect in the non-normative example - DH calling the DR Revocation Endpoint

• Proposed action: closed with no change.
• The example referenced is for the Data Recipient calling the Data Holder and appears correct using the Self-Signed JWT method. It is different to the Private Key JWT method for Data Recipients calling Data Holders.

#409: Dynamic Client Registration Response Time NFR

• Proposed action: update DCR NFRs
• Affects: DCR APIs (PUT/POST/DELETE) but does not affect GET
• Current State: DCR NFRs classified as High Priority APIs with a 95th percentlile average response time of 1000ms

#411: Clarification of x-fapi-interaction-id header

• Affects: Public (Unauthenticated) APIs
• x-fapi-interaction-id is not intended for unauthenticated APIs
• Option 1: Clarify that it must be returned or played back for authenticated APIs only (optional for unauthenticated)
• Option 2: Re-purpose the x-fapi-interaction-id for all Data Holder APIs (mandatory for both authenticated and unauthenticated resource APIs)
• Option 3: Include a CDR specific correlation ID header

#447: CORS typos in CDR

• Proposed action: Correct documentation for CORS section and add supplementary explanatory text

- <p>Cross-origin resource sharing (CORS) must be enabled (ie. <code>Access-Control-Allow-Origin</code> set to &quot;*&quot;) for the following end points:</p>
+ <p>Cross-origin resource sharing (CORS) protections must be disabled (ie. <code>Access-Control-Allow-Origin</code> set to &quot;*&quot;) for the following end points:</p>

 <ul>
 <li>Get Status</li>
 @@ -5131,6 +5131,12 @@ <h2 id='cors'>CORS</h2>
 <li>Get Product Detail</li>
 </ul>

+ This will effectively ensure there is no Same Origin Policy (SOP) for these end points.
+
+ Inversely it is recommended that all other endpoints apply a proper domain, allowed methods, and allowed headers in the CORS response headers. Using <code>Access-Control-Allow-Origin</code> set to &quot;*&quot; is generally considered a security misconfiguration of CORS unless it is intentional for a valid purpose (above end points are necessary).
+
+ See: <a href="https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing">OWASP web security testing guide (WSTG)</a> for additional information of how to properly configure CORS.

#479: Clarification on Minimum Algorithm Required for JARM

• Proposed action: No change - defer to JWS requirements for JARM

• Data Holders advertise signing and encryption algorithm support via their OIDD:

  • authorization_signing_alg_values_supported -- JSON array containing a list of the JWS [RFC7515] signing algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to sign the response. The none algorithm, i.e. a plain JWT, is forbidden.

  • authorization_encryption_alg_values_supported -- JSON array containing a list of the JWE [RFC7516] encryption algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.

  • authorization_encryption_enc_values_supported -- JSON array containing a list of the JWE [RFC7516] encryption algorithms (enc values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.

  • These are negotiated through dynamic client registration services

#487: DCR APIs non-normative examples would benefit from clarification

• Proposed action: Fix non-normative example

#489: v1.15.0 More ambiguity into x-fapi-auth-date not less

• Proposed action: Fix documentation
• Change Banking API endpoint descriptions to be:

The time when the customer last logged in to the Data Recipient Software Product as described in [FAPI-R-Draft]. 
Required for all resource calls (customer present and unattended). Not required for unauthenticated calls.

#490: Admin CDR OpenAPI specification missing error definitions

• Proposed action: fix Admin API Swagger
• Preference is to import shared definitions from a common baseline Swagger, else include duplicate definition in the Admin API swagger JSON

#497: CommonEmailAddress - address format documentation

• Proposed action: fix documentation

#491: ID Token algorithm support requirements are ambiguous

• Proposed action: fix documentation

#492: Admin API Definitions Request Body Incorrectly Nested

• Proposed action: fix Admin API Swagger

#494: Response payload structure description error

• Proposed action: fix documentation

#500: ADR should not initiate Authorisation Code Flow with PKCE if the Data Holder does not support this flow

• For discussion

• DSB/AEMO Issue #477 DSB and AEMO to meet offline and agreed on an FDO for Issue 477.
  • Carried over from MI10, DSB are in discussion with AEMO and once an FDO is agreed we will update the issue and close this action.
• Biza to raise a ticket on energy usage and DSB to table this in their discussions with AEMO.
  • The issue was raised in a recent AEMO discussion and there is an assessment underway to understand the impact. Background work and early advice indicates the issue will impact 10s of thousands of consumers so a solution is needed. There's still an action on Biza to raise a ticket once impact assessment is concluded.
• DSB to update Noting Paper 248 to clarify PRD hosting obligations.
  • Completed on 11/05/2022.

• 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 is primarily a discussion around nominated reps, but also additional details for other parties who are account holders, non primary consumer, where consent is required for joint accounts and whether personal information about those people could be shared, e.g. first name last name of other account holders associated to the joint account. This issue is currently with Treasury Rules Team and OAIC and we're hoping we'll get a response this week.
• DSB (In Progress) Issue #458 DSB to include examples to describe the transition to FAPI 1.0.
  • Rolled over from MI11 to track progress ensuring we have captured the whole sequence correctly, there is more work to do on non normative examples.
• 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.
  • DP245 addresses a gamut of use cases that we're putting focus on, including whitelisting which is the subject of 418. DP245 will incorporate further whitelisting considerations.
  • DSB to update 418 indicating outcome of DP245 is required.

• ACCC Issue #453 ACCC to investigate operational issues with CTS to resolve discrepancies in Register behaviour.
  • Discussion revisited previous concerns around:
    • no FDO on the change to no upper bound indicating immediate compliance when v1.17.0 is published;
    • the dependency on ACCC Operations;
    • absence of out of band communications; and
    • unsatisfactory resolution timeframes when issues are raised.
  • ACCC welcomes feedback via the channels posted on the issue and continues its investigation into CTS discrepancies, this action will remain open until resolved.
  • Ivan to review and update the way in which DP237 clarifies the boundaries between ACCC Operational Responsibility and the remit of the Standards.
    • DP237 was published on 12/05/2022 incorporating this clarification.
• DSB to raise an additional CR to address the FDO request by ACCC in MI 11 Issue 488.
  • Issue 507 has been raised to proposed an FDO for unsupported authorisation scopes and is an iteration candidate for MI11.
• DSB to break this CR into two topics and invite the community to comment to help drive priority Issue 427.
  • Issue 508 has been raised. However, its important to note that 508 has not been prioritised for MI11.

• DSB/ACCC: DSB to work with ACCC to explore opportunities to reconcile actions raised during the Maintenance Iteration.
  • In progress; the retrospective did highlight there are opportunities to be more transparent.
• ACCC to provide feedback to the community on what their release schedule will look like.
  • In progress; the ACCC is working on providing a release schedule for those items footnoted in DP237.

Energy

• Issue 472: Modify Energy Plans structure to allow Time of Use based Controlled Load rates
  • Thanks to Biza for contributing to the analysis on this item, it is in progress and has been prioritised as a candidate for MI11.
• Issue 477: Secondary Data Holder Planned Outages and Status
  • Late comments received in MI10 indicated the need for further discussion, particularly with regard to requirements for AER, prioritised as a candidate for MI11.
• Issue 495: GetAgreedPaymentSchedule API - manualPayment section should have paymentFrequency instead of billFrequency field
  • Making changes to manual payment to incorporate payment frequency with bill frequency, prioritised as a candidate for MI11.
• Issue 502: Review ENUM values for representation of days in Energy Standards
  • This CR was created while consulting on other CRs in MI 10, acknowledging a consistent way to represent days across sectors is required, prioritised as a candidate for MI11.

CX

• Issue 485: Common Data Clusters altered for Energy Data Language
  • This CR was raised because customer data defined in the Rules for the Energy Sector does not align with banking even though it's common data.
  • CX is consulting with the Treasury Rules team on options.
• Issue 427: Standards & Guidelines regarding Sponsored Accreditation
  • The consent model will be consulted on in DP229 when the Government is no longer in Caretaker Mode.

Register

• Issue 480: 1.13.0 appears to have broken pseudonymity of Pairwise Identifiers
  • This was raised some time ago as a result of questions in Thursday’s CDR Implementation Call, it has been prioritised in MI11 for that reason.
• Issue 484: 1.13.0 Appears to have introduced new SSA error behaviours
  • This was raised some time ago as a result of questions in Thursday’s CDR Implementation Call, it has been prioritised in MI11 for that reason.
• Issue 481: Provide timeline of when multiple sectors per data holder brand will be supported
  • While design intends to allow the payload to span multiple sectors, currently it is limited to one sector.
  • ACCC to share the details of their plan to support this change.
  • INDUSTRY to provide feedback to indicate when data holders with multiple sectors will need to be represented in the Register.
• Issue 486: Allow ADRs to specify scopes for a Software Statement Assertion (SSA) to support cross industry software products
  • Debate continues on whether this risk is addressed through operational means or whether a technical control is required. We will seek to address this during the maintenance iteration
• Issue 431: Register participant statuses do not detail data holder behaviour when ADR is revoked and SP inactive
  • Originally deferred in MI10
  • Will seek to address this iteration
• Issue 510: Register API error codes need to be aligned with the CDS standardised error codes
  • During the MI we will need to ascertain the priority and how transition may work
• Issue 427: Standards & Guidelines regarding Sponsored Accreditation
  • While Issue 427 is subject to consultation under DP229 we do not have a sense of urgency for automated onboarding and certificate issuing in Issue 508 therefore it will not be prioritised in MI11.
    • 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

• Issue 491: ID Token algorithm support requirements are ambiguous
  • Non-breaking change limited to a documentation fix.
  • DSB to stage the change and consider a patch release.

The following sections list a significant number of open changed requests which have been analysed to offer a proposed approach to resolving them, additionally a relative size and effort has been assessed in order to determine the feasibility of addressing them in MI11. The earlier conversation on how to handle small documentation changes, see Other Business - Errata and small changes, is an excellent outcome and will be tested in this MI. This will resolve a number of easy documentation changes to clean up the backlog.

• There were no objections to this approach.

InfoSec

• Issue 418: CDR Data Holders outbound connection whitelisting
  • DSB to update this issue to confirm it will be addressed in DP245.
• Issue 435 Nominated representative end user for non-individual consumers
  • Carried over from MI 10 will be continued and completed in MI11.
• Issue 458: FAPI 1.0 Non Normative Examples
  • Carried over from MI 10 will be continued and completed in MI11.
• Issue 500: ADR should not initiate Authorisation Code Flow with PKCE if the Data Holder does not support this flow
  • Not discussed.
  • prioritise Issue 500 for discussion on 25/05/2022
• Issue 172: Validation of client_id parameter in client authentication requests
  • Clarification is required across PAR/AuthZ/Token endpoints and whether the client_id is required
• Issue 200: Documentation defect in the non-normative example - DH calling the DR Revocation Endpoint
  • Non normative example is correct however the issue will be kept open to enable feedback during the MI, if no feedback is received the issue will be closed with no change.
• Issue 447: CORS typos in CDR
  • No objections to proposed change.
• Issue 479: Clarification on Minimum Algorithm Required for JARM
  • CDS relies on JWS and JWE in JARM specification.
  • No change required.
  • DSB to update the issue with explanation to elicit feedback from the community for further discussion.
• Issue 487: DCR APIs non-normative examples would benefit from clarification
  • No objections to change.
• Issue 489: v1.15.0 More ambiguity into x-fapi-auth-date not less
  • Not discussed.
  • Prioritise Issue 489 for discussion on 25/05/2022.

High Level Standards

• Issue 78: HTTP Header to be returned in the case where the request is not entirely well formed and a large page size is requested
  • DSB proposed closing the issue as no change is required. No objections.
• Issue 411: Clarification of x-fapi-interaction-id header
  • Affects: Public (Unauthenticated) APIs
  • x-fapi-interaction-id is not intended for unauthenticated APIs
  • Option 1: Clarify that it must be returned or played back for authenticated APIs only (optional for unauthenticated)
  • Option 2: Re-purpose the x-fapi-interaction-id for all Data Holder APIs (mandatory for both authenticated and unauthenticated resource APIs)
  • Option 3: Include a CDR specific correlation ID header
  • DSB to update the issue with these details, preferencing Option 1
• Issue 494: Response payload structure description error
  • Not discussed.
  • Prioritise Issue 494 for discussion on 25/05/2022

Common APIs

• Issue 497: CommonEmailAddress - address format documentation
  • Simple documentation fix.

Non-Functional Requirements

• Issue 409: Dynamic Client Registration Response Time NFR
  • DCR is not perceived as a high priority call and consensus was to re-classify DCR as an unattended call.
  • Request for data from DHs to support this change, NAB agreed however despite results would still like to see the call reclassified.
  • One Data Recipient attending the call confirmed there was no issue with the length of time it took as long as the call was successful.
  • There has been observations of DRs crossing IP ranges, as a result it appears it would be reasonable to consider NFRs for ADRs to serve JWKS. However, it's believed the Rules do not support ADRs NFRs therefore it's important for DHs to log outbound calls to DRs for audit purposes.
  • NAB to provide numbers on DCR call response times.
  • ACCC (VC) to provide advice on whether the rules support ADR NFRs.
  • DSB to progress the reclassification of the DCR NFR and other options based on advice from NAB and ACCC.

Admin APIs

• Issue 490: Admin CDR OpenAPI specification missing error definitions

  • Straight forward documentation fix to ensure swagger is full and complete.

• Issue 492: Admin API Definitions Request Body Incorrectly Nested

  • Not discussed.
  • Prioritise Issue 492 for discussion on 25/05/2022.

Banking

• Issue 229: Service field in the Get Transaction Details API
  • Agreed to carry over to MI12.
• Issue 471: Additional credit card fields
  • Agreed to carry over to MI12.

Banking / CX

• Issue 470: Overloading of banking language for scopes / data clusters
  • The CX Team identified an issue with overloading terms at the time the consumer gives consents, however there is no sense of priority to resolve the issue. At this stage there isn't a clear solution and the CX team would like to remove the issue from this iteration to undertake analysis before presenting options to the community.
  • No objections.
  • DSB to remove 470 from MI11

Errata and small changes

• Biza offered a suggestion to create a CR as part of MI to allow raising and consolidating minor changes (such as text corrections or description clarifications) that do not materially change the standards which can be easily addressed. Such as creating an issue where comments on documentation errors can be posted for consideration.
  • Consensus was to support this concept.
  • DSB to consider options and advise on an approach.
    • Issue 511 has been raised to simplify the management of minor text or description issues.

Thematic Changes

• DSB proposed thematic changes to endpoints where consultation on an endpoint could occur over a number of maintenance iterations without formalising an FDO until all related changes had been agreed on.
• Leapfrogging was also suggested, whereby one version is bypassed in preference for a later version to enable the bundling of development effort instead of requiring small incremental changes overtime.
• Comments on Issue NNN relate.
• Preference is to bundle as many changes as possible into a single version and there was consensus to consult on changes to endpoints over multiple MIs.
• DSB welcomes further comment from the community and will proceed on this basis in preparing MI12.

InfoSec

• 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 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 Business

• DSB to consider options and advise on an approach for Errata and small changes.
  • Issue 511 has been raised to simplify the management of minor text or description issues.

• Progress actions and preparation for Maintenance Iteration Meeting on 25 May 2022.