DSB Maintenance Iteration 5: Iteration Checkpoint: Agenda & Meeting Notes (15th October 2020) - ConsumerDataStandardsAustralia/standards GitHub Wiki

Date and time: 15/10/2020, 1pm - 2.00pm AEST (2pm - 3.00pm AEDT)
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

  • (Done) DSB to prioritise Issue #247 in this week's call
  • (Done) DSB to provide updated wording for the aud claim description to Issue #325
  • (Done) DSB to present options discussed on the call to issue #219
  • (Pending) DSB to follow up with the ACCC regarding legal liabilities regarding access token revocation if this was changed to a SHOULD for Issue #240
  • (Pending) DSB to follow up with ADRs to get volume/frequency metrics for loss of refresh token issues regarding Issue #219
  • (Cancelled) CBA to update Issue #307 whether (and how) this would impact CBA's brands and the key issue to solve
  • CBA to provide options for dealing with #315 - Obligation based standards
  • DHs to provide implementation impact analysis for Issue #325

For discussion

NPP update

New Change Requests

  1. #247: ADR Revocation Endpoint
  2. #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
  3. #309: paymentsRemaining cannot currently be 0
  4. #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
  5. #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
  6. #319: [1.5.0] Missing Changelog Item: Maturity Instructions
  7. #321: [1.5.0] Clarification of future obligation dates

Updated Change Requests

  1. #300: Alternate implementations for one-time consent
  2. #322: Incorrect x-fapi-auth_date Example
  3. #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
  4. #315: Obligation date-based standards
  5. #150: A loan may have no end date but loanEndDate is mandatory
  6. #219: Allow retrieval of current refresh_token by arrangement ID

Error URN structure

  • Update on progress
  • Approach and timeframes

Discovery Service

  • Request for requirements elicitation
  • Key business problems to solve

Open Change Requests For Consultation

This is the list of change requests and Decision Proposals under consultation through this iteration

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

Any other business

For discussion

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

#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

  • This meeting discussed issues #307, #247, #301, #309, #311, #318, #319, #321

Issue #307

  • CBA has retired this issue as it is no longer applicable to their solution. Brands will be individually presented to market as distinct Data Holders

Issue #247

  • DSB clarified that it will not consider removal of the Data Recipient revocation end point
  • The view is that other events and push notifications may be useful in future
  • Some ADRs provided confirmation that they don't see this as a burden and support ADR hosted endpoints for notifications and revocation
  • Discussed the need for an adjacent facility for ADRs to query consent to get the status of consent and authorisation details
  • This could help overcome issues with ADR outages or DH outages allowing the ADR to get an updated status of all active consents
  • DSB to request that the second concern of an adjacent polling method be raised as a separate change request

Issue #301

  • Currently, payeeReference and nickname only apply to the PaymentScheduledPayment
  • Agreement that allowing payeeReference and nickname for each PaymentScheduledPaymentSet is supported to tailor / individualise payee reference and nickname for each payee.
  • Discussed continuing to allow a conditional payeeReference and nickname at the top-level which can be overridden by the payeeReference and nickname at the PaymentScheduledPaymentSet level
  • This would introduce a breaking change because the PaymentScheduledPayment would change payeeReference to be conditional and it would introduce an optional nickname and conditional payeeReference in PaymentScheduledPaymentSet
  • This would version each of Get Scheduled Payments For Specific Accounts, Get Scheduled Payments Bulk, Get Scheduled Payments For Specific Accounts to v2
  • Future dated obligations should consider whether other changes could be bundled into changes to these end points rather than setting an obligation date for v2 endpoints that only introduce this change

Issue #309

  • paymentsRemaining in the PaymentScheduledPaymentSet wasn't intended to be historical
  • paymentsRemaining = 0 would be a defunct or completed payment schedule
  • Simplest change is to clarify the intended behaviour and update the example to be "1" not "0"
  • If DHs see benefit to allow historical scheduled payments, this could be included as a future change provided there is clear need and benefit

Issue #311

  • Issue regarding downgrading of payloads
  • DSB to publish recent clarifications on going-forwards position on payload and end point versioning
  • DSB to assess if a fix is required and provide an update to the issue to progress

Issue #318

  • Whilst enums were re-ordered they weren't strictly alphabetically ordered, they were ordered for human readability
  • DSB will request if strict ordering or natural sort order is preferred to be adopted and followed.

Issue #319

  • Recognise this is errata and will be fixed in the maintenance iteration 5 release

Issue #321

  • Base rate is intentional and is intended to mean one of FIXED, FLOATING, MARKET_LIMITED, INTRODUCTORY and VARIABLE
  • BONUS and BUNDLE_BONUS rates must be in addition to the base rate
  • The data standards will be updated to correct and clarify this

Other business

None.

Next Steps

Actions

  • DSB to request that the second concern in Issue #247 of an adjacent polling method be raised as a separate change request
  • DSB to publish recent clarifications on going-forwards position on payload and end point versioning to Issue #311