Date and time: 22/09/2021, 2pm - 3.30pm AEST
Location: WebEx
Dial-in details:

• https://treasuryau.webex.com/treasuryau/j.php?MTID=m6786d3cadd2da38bd3ae2bf7cca07212
• Dial In Number: +61 2 9338 2221
• Dial In Access Code: 265 1917 2241
• Quick Dial: +61-2-9338-2221,,26519172241##

Chair: Mark Verstege, DSB; Ivan Hosgood ACCC
Maintenance overview: Further information
Maintenance project board: See here
Decision Proposal: This maintenance iteration is being consulted on under Decision Proposal 212

• Wait 5 minutes for all participants to join. Kickoff at 2:05pm
• Outstanding Actions
• Release plan: schedule of forwards looking standards releases
• Open Decision Proposals: key consultation dates
• Iteration 9 change request candidates
• Any other business

Meeting notes

• Meeting Notes
• Next steps

This week is the second call of the 9th maintenance iteration. The purpose of the meeting is to discuss options for iteration candidates adopted in the 9th maintenance iteration

• Allow 5 min for participants to join
• Housekeeping
• Overview, purpose and intended outcomes of the meeting

• DSB to extend the length of the iteration call to 90 mins (accomodate Register design issues)
• WBC to create a change request regarding ADR requirements to implement access token revocation
• ANZ to create a change request to better support cursors for returning large result sets.
• StayOrGo to create CDR Register change request for a public API to expose non-sensitive Data Holder metadata to public (unauthenticated) clients

• v1.11.0 was published on June 30th 2021 incorporating CX standards changes and the approved change requests from the 7th maintenance iteration
• v1.11.1: In final stages. This release contains minor documentation errata
• v1.12.0+: There is no v1.12.0 currently planned.

The following decision proposals are open for community feedback

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

All open change requests can be found here:

• Standards Maintenance Issues.
• CDR Register change requests.

Profile scope not aligned with CX standards

• Decision Proposal pending

Issue 395: Does DHs' PAR endpoint require enabling private key jwt client authentication in addition to request object validation?

• Proposed to close the issue without change. PAR required client authentication. CDS aligns to the upstream specification and does not intend to deviate.

Issue 397: Transaction Security Ciphers

• Propose to reject the request to include additional ciphers not explicitly defined in FAPI
• Propose to change the data standards text for cipher support to simply reference section 8.5 of the FAPI Advanced Profile (Read/Write).

Cipher suites SHALL only be permitted in accordance with section 8.5 of [FAPI-RW].

This has previously been discussed in the FAPI WG with the reference to [BCP 195] and TLS 1.3 being considered. The change proposed above will improve upstream FAPI alignment.

Issue 406: Change Request to make 'scope' optional in the token end-point response in FAPI

• Community feedback indicates preference to retain current ID2 specification support. Change to 'scope' requirement to be introduced when FAPI 1.0 transition is agreed, not as cherry picked selective changes.

Issue 150: A loan may have no end date but loanEndDate is mandatory

• Limited community feedback.
• WBC indicated that some of their loan accounts do not have an end date or repayment frequency, but the loan is still currently active.
• Propose to support WBC's proposed change because there has not been significant feedback advising this is an impact to ADRs.
• Proposed guidance:
  • If the loan does not have any repayments remaining and it has been closed, Data Holders should omit the BankingLoanAccount entity entirely
  • Otherwise, repaymentFrequency, loanEndDate and nextInstallmentDate are optional.
• What impacts are there to existing ADR implementations? Should a future dated obligation be defined to accomodate this?
• Proposed that this change does not change the version of the endpoints.

Issue 396: Define new Digital Wallet Payee Type to relevant schemas

• Currently Payee APIs do not support Digital Wallet contacts
• Intent: provider-agnostic solution for digital wallet payees
• Requirements:
  • Payee may be one or more digital wallet providers.
  • Digital wallet provider should be extensible to support new entrants
  • Digital wallet contact has a name and identifier
  • Identifiers may be represented by one or more defined types such as email phone, name etc.
  • PayPal contacts may represent a personal or business payee, but this attribute is not shown to customers or a characteristic that can be filtered or queried in PayPal
  • Additional provider specific details may be required in future, but no immediate needs are identified to support PayPal contacts
• Proposal:
  • Extend BankingPayee type to include DIGITAL_WALLET
  • Extend BankingPayeeDetail payeeUType to include digitalWallet
  • Extend BankingPayeeDetail with new BankingDigitalWalletPayee entity

"BankingDigitalWalletPayee": {
      "type": "object",
      "required": [
        "name",
        "identifier",
        "type",
        "provider"
      ],
      "properties": {
        "name": {
          "type": "string",
          "description": "The name assigned to the digital wallet by the owner of the wallet or the display name provided by the digital wallet provider"
        },
        "identifier": {
          "type": "string",
          "description": "The identifier of the digital wallet (dependent on type)"
        },
        "type": {
          "type": "string",
          "description": "The type of the digital wallet identifier",
          "enum": [
            "EMAIL",
            "CONTACT_NAME",
            "TELEPHONE"
          ]
        },
        "provider": {
          "type": "string",
          "description": "The provider of the digital wallet",
          "enum": [
            "PAYPAL_AU"
          ]
        }
      }
    }  

Example:

{
  "payeeId": "ID Permanence resource identifier",
  "nickname": "The nickname provided by the consumer for the contact OR a display name provided by the wallet provider. For PayPal this will be a display name e.g. 'John Smith'",
  "description": "If applicable, a description of the payee contact. For PayPal this data is not applicable",
  "type": "DIGITAL_WALLET",
  "creationDate": "If applicable, the creation date of the payee contact. For PayPal this data is not available.",
  "payeeUType": "digitalWallet",
  "digitalWallet": {
      "name": "For PayPal this will be a display name e.g. 'John Smith'",
      "identifier": "[email protected]",
      "type": "EMAIL",
      "provider": "PAYPAL_AU"
  }
}

• Implementation Considerations
  • Breaking change for consumers to Get Payees v1 and Get Payee Detail v1
  • Future Dated Obligation for Get Payees v2 and Get Payee Detail v2
  • If the Data Holder does not support digital wallets, the Data Holder can fully support v2 immediately (accept both v1 and v2)
  • 6-month lead time would impose a FDO of 31st of March 2022. Data Holders can support v2 as early as is practical but no later than 31st of March 2022
  • Propose retirement of v1 APIs 1 month after v2 FDO. Therefore, DHs can retire v1 any time after 31st April 2022

Issue 405: Alternative mechanisms for OTP

• Macquarie Bank to present sequence diagram for decoupled OTP authentication

Issue 174: Update Register APIs to search for and differentiate between archived entities

• Due to capacity issues with the RAAP team and planning alignment of similar changes, it is proposed this issue be deferred and group this into API changes for energy which will be documented in a decision proposal.

Issue 126: Consider changing statement in Certificate Management about the use of ACCC CA issued certificates for ADR end points

• The definition in the Register design simply reflects the CDS, where either a public or ACCC CA issued certificate can be used to secure TLS endpoints. Propose that this issue be included in scope of the upcoming the threat modelling decision proposal given the relationship to that security review work.

Issue 123: Consider identicons to allow DHs to provide multiple attributes to map to individual accreditations

• For discussion

Issue 189: RegisterDataHolderAuth schema in GetDataHolderBrands descriptions to be clarified

• Update descriptions in the swagger definition

Issue 188: SSA definition: Deprecation of revocation_uri

• Define deprecation schedule for the revocation_uri. Will also help as we will be defining the change management of SSAs which hasn’t been formalised

Issue 186: Documentation improvement: JWT Signature verification requirements during the DCR flows

• For discussion

Issue 175: Publish an endpoint version schedule to document the introduction and deprecation of Register and DCR endpoints

• For discussion

Issue 169: CDR Register OpenID Configuration does not specify token signing algorithm support

• For discussion

• Address any other business arising from the community

Actions

• --WBC to create a change request regarding ADR requirements to implement access token revocation-- This action has been closed
• StayOrGo to create CDR Register change request for a public API to expose non-sensitive Data Holder metadata to public (unauthenticated) clients. Action has been completed and CDR Register Issue 187 has been created

Binding NFRs

• The NFR decision was approved by the Data Standards Chair. NFRs are now immediately binding
• James provided an overview of what this means and requested where specific changes are required that participants raise change requests for consideration in the Standards Maintenance iterations
• Issue 407 was raised at the request of the OAIC.
• Participants agreed to include Issue 407 in the scope of iteration 9 candidates
• Discussed that 407 whilst being a documentation change requires the approval of the Chair. Would be considered in a 1.12.0 or future release

Release Plan

• Energy decisions have been approved and will result in a new release (1.12.0 or above)
• NFRs have been made binding and will result in a new release (1.12.0 or above)
• 1.11.1 is pending release. No further feedback received on staged changes

Change Requests

• Issue 404:

  • DSB provided an update that this will be consulted on within a Decision Proposal incorporating CX and InfoSec considerations.
  • Proposal likely to be released for consultation in the next week

• Issue 395:

  • Participants supported no change

• Issue 397:

  • No issues raised with aligning to FAPI 1.0 statement for cipher support. This should be incorporated in DP209 because currently the CDS relies on FAPI ID2 which does not have the same statement.

• Issue 150:

  • No issues raised with the change from mandatory to optional for the fields
  • Changing to optional will result in a breaking change for ADR clients
  • Creation of a v2 will result in Future Dated Obligation and v1 endpoint retirement obligations
  • Request for feedback on proposed obligation dates
  • If DHs cannot schematically comply to v1 responses they must omit the loan entity in the account detail response per previous guidance

• Issue 396:

  • No issues raised - proposed structure was supported
  • Proposed future dated obligations were accepted in principle

• Issue 405:

  • Macquarie presented the authentication flow
  • Two flows: native authenticator app flow and fallback to SMS OTP
  • Leverages decoupled backchannel authentication and push-to-approve after a biometric authentication
  • Gives rise to CX considerations (guidelines and standards)
  • ADRs remain agnostic (no impact)
  • Better supports Data Holder choice
  • OTP was introduced to prevent phishing risk (vs password)
  • App authentication would meet this obligation
  • Discussed the current wording of the proposal needing tightening up and improvement

CDR Register Issues

• Issue 174:

  • No API change in this iteration
  • The RAAP team will consult in conjunction with other intended API changes to support the energy sector
  • This approach will limit endpoint versioning

• Issue 126:

  • Will defer to (and be included) in Decision Proposal 211 scope

• Issue 113:

  • Deferred to next iteration

• Issue 189:

  • Descriptions for fields need improvement. This is a documentation fix only

• Issue 188:

  • ADR revocation_uri is not longer supported
  • This change seeks to remove the legacy field from the SSA generated by the Register
  • Has impact to CTS and changes will need to be made to the testing suite
  • Question was asked whether ADRs must update their client registration with each Data Holder after this change is made?
  • In theory, the parameter is deprecated so it should not be necessary but for hygiene reasons ADRs should be encouraged to update the SSAs held in their DH client registration

• Issue 186:

  • Update to sequence diagrams and supporting documentation is required. No changes to the specifications.

• Issue 175:

  • CDR Register doesn't have an endpoint versioning schedule
  • This change is to align to the Consumer Data Standards which publishes an endpoint versioning schedule for all APIs

• Issue 169:

  • Require an update to the swagger documentation

• With the move of the Register standards, a participant asked if the backoff polling patter text or clarification on GitHub Issue 367 should be included in the move
• Agreed the DSB will consider this in the move of the standards with the potential to include a qualifying statement that Data Holders should take reasonable measures to communicate consent withdrawal

• None