DSB Maintenance Iteration 5: Finalisation of Iteration Scope: Agenda & Meeting Notes (30th September 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki

DSB Maintenance Iteration 5 - Finalisation of Iteration Scope - Agenda & Meeting Notes (2020-09-30)

Date and time: 30/09/2020, 2pm - 3pm AEST Location: WebEx

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

Agenda

Meeting notes

Introductions

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

Actions

Decision Proposals

  • Enhanced Error Handling: #119, #120, #121, #122 and #127
  • Discovery Service (see DP #135) - DP TBA
  • Metrics and Reporting roadmap + Metric API v2 - DP TBA

Change Requests

The following change requests have been proposed for this iteration:

  1. #152: CRN in BankingBillerPayee should be optional
  2. #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
  3. #229: Service field in the Get Transaction Details API / #181
  4. #300: Alternate implementations for one-time consent
  5. #175: Premature Completion of Consent (Hybrid) Flow
  6. #219: Allow retrieval of current refresh_token by arrangement ID
  7. #240: 'SHOULD' for access token revocation
  8. #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
  9. #307: Make Metrics brand aware
  10. #315: Obligation based standards
  11. #150: A loan may have no end date but loanEndDate is mandatory
  12. #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
  13. #309: paymentsRemaining cannot currently be 0
  14. #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
  15. #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
  16. #319: [1.5.0] Missing Changelog Item: Maturity Instructions
  17. #321: [1.5.0] Clarification of future obligation dates
  18. #247: ADR Revocation Endpoint

#152: CRN in BankingBillerPayee should be optional

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/152

Overview:

  • CRN in BankingBillerPayee is mandatory but CRN is not always known
  • If CRN is not available, the biller cannot provided (to avoid breaking the mandatory constraint)
  • Iteration 4 proposed CRN be conditional and introduced crnType with July obligation date
  • crnType is mandatory however is is not always derivable
  • Options to deal with CRN/crnType:
    • Define a default crnType when not known e.g. VARIABLE_CRN
    • Define an UNKOWN enumeration for crnType
    • Make both CRN and crnType conditionally optional

Decisions to be made:

  • Are any urgent changes required to support November
  • Target state, what changes are required in addition to what was approved in Iteration 4

#320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/320

Overview

  • See #152
  • For consultation in conjunction with #152

Decision to be made:

  • Should a default crnType apply or should crnType be conditional?

#229: Service field in the Get Transaction Details API / #181

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/229, https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/181

Overview:

  • Extend support for new NPP Osko overlays and SCT
  • DSB in discussion with NPPA to progress

Decisions to be made:

  • Pending proposal from DSB

#300: Alternate implementations for one-time consent

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/300

Overview:

  • One-time consent currently assumes sharing_duration = 0 and couples collection and use
  • Loss of access token, DH availability or network issues impact ability for ADR to collect.
  • Places burden on the consumer to re-consent where technical issues are encountered
  • Separation of collection and use consent is permitted under the Rules for one-time consent only* (i.e. provided that the ADR collects only once, otherwise they are in breach)
  • E.g. and ADR can use a sharing_duration = 24hr (e.g., or similar) for one-time collection and ongoing use
  • ADRs would be required to request consent for ongoing use and make this duration clear vs collection consent
  • Would allow ADRs to collect in a one-time capacity but have an extended period of use (e.g. 90 days) provided the consumer consents
  • Note: Currently the Rules don't permit separation of collection and use for on-going consent

Decisions to be made: In review by ACCC and DSB

  • CX Guidelines and Standards to provide guidance on ADR presentation of collection consent and use consent
  • Technical standards changes:
    • Define the time-period of collection for one-time use e.g. 24 or 48 hrs
    • Define standards for revocation of collection consent after successful data collection

#175: Premature Completion of Consent (Hybrid) Flow

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/175

Overview

  • Authorisation codes may be lost in transit at authorisation time
  • Tokens may be lost in transit when the ADR attempts exchange for the authorisation code
  • Authorisation codes are short-lived use-once codes and cannot be replayed
  • If any loss of code or token occurs, the ADR does not have confirmation of authorisation
  • There is a CX concern where the DH would now show consent as "active"
  • Broad agreement that consent only becomes "active" after confirmation of handover once the ADR takes possession of the relevant tokens

Decisions to be made

  • Define consent / authorisation lifecycle
  • Define _when_consent is considered "active"
  • Determine what occurs where the consumer's consent is "awaiting authorisation":
    • Can the ADR obtain an authorisation code and/or tokens?
    • Must pending consent be destroyed?
    • Can the DH initiate sending a new authorisation code where consent is "awaiting authorisation" after a period of time
  • Define CX considerations consent "awaiting authorisation" (i.e. "pending" consent)

#219: Allow retrieval of current refresh_token by arrangement ID

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/219

Overview

  • Loss or refresh token can occur for a variety of reasons including
    • ADR incorrectly revokes tokens prior to consent being revoked (note: whilst possible this is considered an implementation fault of the ADR client and temporarily obviated by continuing consent revocation via the DH oAuth Token Revocation end point until Feb 2021)
    • DH cycles refresh tokens but the ADR does not obtain a new refresh token before their existing refresh token expires
    • Refresh token is lost in transit (ADR does not take receipt of a requested refresh token)
  • In these situations, effort shifts to the consumer: ADR must ask the consumer to re-consent to continue providing their goods or service
  • Proposal is to use the cdr_arrangement_id as a secondary "secret" for exchange of a new refresh token
    • This would not cater for situations during initial authorisation where the authorisation_code is exchanged to obtain the cdr_arrangement_id and tokens
  • Alternatively, could be handled via
    • "confirmation of handover" in #175
    • Disallowing refresh token cycling by data holders

Decisions to be made

  • Agree on approach to deal with potential loss of refresh token

#240: 'SHOULD' for access token revocation

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/240

Overview

  • Currently, DHs must support revocation of Access Tokens
  • RFC7009 does not require AT revocation (it is a SHOULD) however this is discussed in RFC7009 Security Considerations noting that it "contributes to overall security and privacy since it reduces the likelihood for abuse of abandoned tokens"
  • There is concern that compromised access tokens can be used by malicious users to obtain consumer data
  • "Compromised" access tokens may be valid for up to 10 minutes
  • This risk is minimised because access tokens being bound to the private key of the client (HoK)
  • Likely risk is that the client software continues to collect data (e.g. via a scheduled job) using a valid AT for up to 10 minutes after a consumer revokes consent
  • Whilst JWT based ATs may reduce verification calls to the DH Authorisation Server, the Resource Server still needs to verify the access granted is still valid (e.g. customer represented by the sub isn't suspended, account hasn't been removed from consent, joint account holder hasn't withdrawn consent etc.)
  • This is only a consideration in instances where the ADR explicitly asks the DH to revoke an AT
    • Actual usage of this service by ADRs is unknown

Decisions to be made

  • Whether to continue mandating Access Token revocation (if the ADR explicitly asks to revoke ATs)

#325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/325

Overview

  • In v1.4.0 the data standards clarified the audience claim for Data Recipients client authentication to Data Holders based on community feedback
  • Whilst this may work for the token endpoint, it does not work for PAR end point
  • Proposal is a Future Dated Obligation of Feb 2021 be introduced
  • Would require ADRs (existing and new entrants) to align to this obligation date and implementation

Decisions to be made

  • Are ADR implementations correct per RFC7523?
  • What effort is required for ADR clients to correctly align to the Consumer Data Standards (Token Endpoint URL)
  • What implementation considerations and future dated obligations are necessary (if any)
  • Should the aud claim be qualified to:

aud: The issuer identifier URL of the authorization server according to [RFC8414] SHOULD be used as the value of the audience.
In order to facilitate interoperability the authorization server MUST accept its issuer identifier, token endpoint URL, or pushed authorization request endpoint URL as values that identify it as an intended audience.

  • Are there any implementation considerations with out of the box Authorisation Service implementations against RFC7523?

#307: Make Metrics brand aware

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/307

Overview

  • Metrics reporting is currently aggregated at the Data Holder level
  • If Data Holders represent multiple brands under one DH instance, the DH cannot report on per-brand metrics
  • This may result in loss of reporting detail at the brand level

Decision to be made

  • Update Metrics to report on Metrics at the brand level not the DH level
  • Assume target Get Metrics v2 for July 2021

#315: Obligation based standards

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/315

Overview

  • All obligations for a given milestone/compliance date can be difficult to understand when applied across versions of the data standards

Decision to be made

  • How can the data standards be represented such that standards making agility is preserved but greater confidence in required compliance obligations is possible?

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

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/150

Overview

  • loanEndDate, repaymentFrequency and nextInstallmentDate can sometimes be absent
  • Applies for some closed accounts and line of credit products
  • Proposals include:
    • Make these fields optional
    • Define a new product category for line of credit products
    • Make the fields conditional for closed accounts

Decisions to be made

  • Should these fields be made optional or conditional for closed accounts
  • Should these fields be made optional or a new product category be defined for line of credit accounts

#301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/301

Overview

  • BankingScheduledPayment expects that the nickname and payeeReference apply to all payments in the associated PaymentSet

Decision to be made

  • Should BankingScheduledPayment include a "display name" for the scheduled payment
  • Should nickname and payeeReference be conditional if they are provided within the paymentSet

#309: paymentsRemaining cannot currently be 0

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/309

Overview

  • paymentsRemaining is defined as a PositiveInteger
  • If there are not further payments remaining, should any scheduled payments be returned?
  • If paymentsRemaining=0 this would imply no further payments and hence no scheduled payment
  • If scheduled payments should show historical payment schedules, then consider allowing paymentsRemaining to be a NaturalNumber and include zero(0) as a valid value

Decision to be made

  • Either update examples to be a PositiveInterger (>= 1), or
  • Change paymentsRemaining to be NaturalNumber and allow zero(0) paymentsRemaining
#314: [1.4.0] BankingProductLendingRate is actually V3 not V2

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/311

Overview

  • Model versions for BankingProductLendingRate were incorrectly versioned
  • Versioning strategy has been clarified such that models will be versioned up the tree when an end point is versioned otherwise the data models will not be versioned

Decision to be made

  • Suggest no backporting and versioning of models strictly follow clarified versioning guidance where breaking changes that result in end points being versioned will increment the model hierarchy

#310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/310

Overview

  • feeType was modified in 1.4.0 to cate for at-cost fees via the new enumeration "VARIABLE"
  • Get Product Detail was versioned to v3 with a Feb 2021 release date
  • Get Account Detail was not versioned accordingly

Decision to be made

  • Whether to version Get Account Detail to v2

#318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/318

Overview

  • Enums were ordered for human readability

Decision to be made

  • Should all enums be strictly Alphabetically or Natural Order sorted?

#319: [1.5.0] Missing Changelog Item: Maturity Instructions

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/319

Overview

  • Errata - missing changelog documenting maturity instructions change added in v1.5.0

Decision to be made:

  • Update release notes for 1.5.0

#321: [1.5.0] Clarification of future obligation dates

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/324

Overview

  • Errata - missing obligations in the Future Dated Obligations table

Decision to be made:

  • Update Future Dated Obligations table in next release

#247: ADR Revocation Endpoint

Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/247

Overview

  • DHs must notify ADRs when consent is withdrawn via the DH dashboard
  • ADRs host consent revocation endpoints to support notification of this event
  • This increases infrastructure costs for ADRs
  • This increases security complexity for the CDR
  • Alternatively, ADRs can poll DHs to obtain the status of consent via the refresh_token "active" claim or richer consent introspection (e.g. authorization_details) or Consent API

Decisions to be made

  • Short term: ADRs continue to host an ADR revocation end point until consent introspection is possible
  • Requirements for DH hosted consent introspection / Consent API
  • ADR preference to continue hosting revocation endpoint vs polling DHs

Meeting Minutes

Notes

  • CBA provided an update on #315 - expecting options to be presented at the next iteration call on 7/10/2020

  • Issues discussed: #315, #152/#320, CDR Register #139, #229/181, #300, #175

  • Decision proposals for Discovery Service and Get Metrics v2 are pending

  • Participants brought up the issue of CDR Register issue #139 in conjunction with Get Metrics v2.

  • The issue currently is that DHs must implement two versions of Get Metrics with two different client authentication models

  • Preference is to consider these are related concerns and dealing with resolving client authentication for Get Metrics prior to July 2021

  • Since there is only one client (the CDR Register) this would require minimal effort on a client implementation perspective

  • Question is whether this is tied into the work on the Discovery Service or Get Metrics v2 or both

  • #152/#320

    • Participants requested that the description be updated as an urgent change for November obligations
    • Request is to clarify the CRN description to permit blank CRNs be provided for Payees that are either variable or intelligent CRNs
    • Agree to deal with the changes for CRN Type as a post-Nov concern to close this issue off
    • Discussed that for scheduled payments, CRN must be present however for payees in an address book, they are conditional based on the type of CRN
    • Community to request this be treated as urgent
    • DSB will action consultation accordingly once this is done

  • #229/181

    • DSB discussing with NPPA - design proposal will be provided after review with NPPA

  • #300

    • DSB to provide confirmation on GitHub that ACCC permits separation of consent for collection and use for one-time consent only. Consultation on Rules 2.0 considers allowing separation of collection and use for ongoing consent but this is currently not permitted under the rules
    • Requires CX considerations / guidelines for consistent language for separation
    • Proposal generally supported to allow one-time consent to permit sharing_duration of 24 hours and ADRs to obtain refresh tokens for making calls to protected resources
    • This would overcome the majority of technical issues without impacting the consumer
    • DSB to summarise the options and position presented

  • #175

    • The current tight binding of token issuance to business consent can result in orphaned consent occurs due to technical issues
    • Strong desire for DSB to define a consent lifecycle to lay the groundwork to solve this issue and related issues
    • Participants request that an "active" consent definition differentiate between technical and business perspectives of consent
    • UX considerations: need to define how consent should be shown by DH and ADR in a pending state
    • Technical standards required to define how long "pending" consent remains "unclaimed" until it is revoked/withdrawn
    • Guidelines / standards required for consumer notifications if this occurs
    • DSB to provide a summary on the GitHub issue and next steps

Other business

  • An additional out of cycle call will be scheduled for Wednesday 07/10/2020 to deal with the list of change requests this iteration

Next Steps