DSB Maintenance Iteration 21: Meeting notes (2 October 2024)

Meeting Notes

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.

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

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.

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.

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

528

Keep open
Some DHs notes they have two different JWKS endpoints (one in config and one in Register)

531

539

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

542

557

552

554

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