-
Notifications
You must be signed in to change notification settings - Fork 55
DSB Maintenance Iteration 21: Meeting notes (2 October 2024)
Mark Verstege edited this page Oct 15, 2024
·
1 revision
- This meeting was the second for MI 21. The purpose of this meeting was to confirm the iteration candidates and commence discussing the change requests.
- Participants also reviewed the issues backlog and performed prioritisation and grooming on the oldest issues.
663 - Maintenance Iteration 21 Holistic Feedback
- Discussed current list of minor changes
659 - Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency
- Technical request tied to future planned work: #183 - Decision Proposal 183 - Purpose Based Consents and #130 - DSB Item - Ability for ADR to request all accounts or identify missing accounts
- ADR participant described use case related to the need to share all accounts for lending use cases
- ADR participant requesting "select all" functionality be elevated to a mandatory standard for DHs to implement
- DSB stated that the existing CX standard (Authorisation: Account selection functionality) and CX guidelines (Authorisation to disclose, Default example) already allow and show 'select all' functionality. Updates to the CX Guidelines for account selection are in progress to further clarify the ability for DHs to implement 'select all' functionality.
- DSB noted that CX Guidelines are optional to implement and while they are not mandatory, the rules indicate that CDR Participants must have regard to them.
- ADR participant stated that making it mandatory for data holders to include the 'select all' function would be preferred
660 - Revise the Availability Requirements NFRs
- ADR participant raised the proposal that outages including a technical message for ADRs not just a customer facing message
- Including the list of endpoints affected during the outage supported by a Data Holder participant and ADRs
- Options discussed:
- Option 1 - 99.5% availability to include planned outages
- Option 2 - Commensurate to digital channels
- Option 3 - Secondary NFR - when scheduled outages are included
- Option 4 - CX standard to require DHs to communicate outages to consumers before and during outages
- Secondary data holder noted that there are needs for regular scheduled outages. High availability limits including planned outages could push a change in architecture if they are set too stringently. Where data doesn't change often, it was also noted that an outage would have less impact.
655 - Get Metrics V5 error metrics documentation
- The proposed change was reviewed and no feedback was provided.
649 - Inconsistent JARM error responses
- One Data Holder noted they have implemented a cancel button for redirection back to the ADR. The DH noted that they considered stopping the journey without an explicit cancel button was necessary for security reasons.
- The DSB noted that when a user is redirected back to the ADR, it is mandatory for an error or success response to be provided according to the specifications.
- DSB mentioned possibly making a ‘cancel’ button mandatory.
- ACTION: Data Holders to provide views on whether they provide a 'cancel' button, and whether it should be mandatory to do so.
666 - Retirement of OIDC Hybrid Flow
- It was noted that some DHs continue advertising hybrid flow
- It was noted by one ADR participant that errors were occurring when trying to update client registration to remove hybrid flow registration
- Noted by the DSB this shall be closed in 1.32.0
- Keep open
- Some DHs notes they have two different JWKS endpoints (one in config and one in Register)
- Addressed in DP338
- Keep open
- Related to timezone defaults
- If pure local time, don’t know how to convert
- How does the ADR know the actual time the holder posted the transaction because of daylight savings
- Keep open
- Dealt with in auth uplift
- Leave open
- Relates to CX guidelines
- Can be progressed once August rules are made
- Leave open
- Could be dealt with in MI21
- Leave open
- Some OTP delivery timeframes will be out of the control of the DH
- Suggested exploring ways to remove friction from the consumer experience and maybe having a metric that's focused on this could help do that just by indicating when a bad OTP mechanism has been implemented
- Noted that some OTP delivery channels like SMS are out of the control of DHs
None