-
Notifications
You must be signed in to change notification settings - Fork 56
DSB Maintenance Iteration 5: Iteration Checkpoint: Agenda & Meeting Notes (15th October 2020)
CDR API Stream edited this page Oct 22, 2020
·
3 revisions
Date and time: 15/10/2020, 1pm - 2.00pm AEST (2pm - 3.00pm AEDT)
Location: WebEx
- https://csiro.webex.com/csiro/j.php?MTID=md498fcab7a2000cbb4b0072b4b266111
- Dial In Number: +61 2 6246 4433
- Dial In Access Code: 165 106 9550
- Quick Dial: +61262464433,1651069550%23%23
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
- Introductions
- Outstanding Actions
- Change Requests For Discussion: change requests and decision proposals for discussion
- Any other business
Meeting notes
- Allow for participants to join
- Housekeeping
- Overview, purpose and intended outcomes of the meeting
- (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
NPP update
New Change Requests
- #247: ADR Revocation Endpoint
- #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
- #309: paymentsRemaining cannot currently be 0
- #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
- #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
- #319: [1.5.0] Missing Changelog Item: Maturity Instructions
- #321: [1.5.0] Clarification of future obligation dates
Updated Change Requests
- #300: Alternate implementations for one-time consent
- #322: Incorrect x-fapi-auth_date Example
- #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
- #315: Obligation date-based standards
- #150: A loan may have no end date but loanEndDate is mandatory
- #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
This is the list of change requests and Decision Proposals under consultation through this iteration
- 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
For discussion
The following change requests have been proposed for this iteration:
- #152: CRN in BankingBillerPayee should be optional
- #320: [1.5.0] BPAY crnType introduced as mandatory and backported into existing version
- #229: Service field in the Get Transaction Details API / #181
- #300: Alternate implementations for one-time consent
- #175: Premature Completion of Consent (Hybrid) Flow
- #219: Allow retrieval of current refresh_token by arrangement ID
- #240: 'SHOULD' for access token revocation
- #325: Future dated obligation for change to how audience is set for Data Recipients calling Data Holders
- #307: Make Metrics brand aware
- #315: Obligation based standards
- #150: A loan may have no end date but loanEndDate is mandatory
- #301: Consider changing BankingScheduledPayment to allow the capture of multiple nicknames and payeeReferences
- #309: paymentsRemaining cannot currently be 0
- #310: [1.4.0] BankingProductFee feeType adds Variable which is a new payload version
- #318: [1.5.0] Missing Changelog Item: (Nearly) All Enumerations Reordered
- #319: [1.5.0] Missing Changelog Item: Maturity Instructions
- #321: [1.5.0] Clarification of future obligation dates
- #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
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
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
Link: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/310
Overview
-
feeTypewas 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
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?
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
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
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
- 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 Accountsto 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
None.
- 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