OTP NFR added to the Consumer Data Standards

[jimbasiq]

Description

The Data Holder authentication OTP implementation is fairly ambiguous in the current standards. We understand this is desired as the OTP method could be a process familiar to consumers of a specific data holder.

A problem we have observed and that we have had consumers raising, is OTPs not arriving in a timely manner. There are two levels to this:

• too slow for a good customer experience
• OTP arriving after a Data Holder's OTP time out period

This change request is specifically for the latter of these two.

Area Affected

Authentication process provided by a data holder.

Change Proposed

We propose to add a clear NFR specifying an OTP must arrive in a certain period. This period must be prior to the Data Holder OTP time out and we suggest it should be less than 2 minutes.

[perlboy]

If this is happening in the wild it's pretty disappointing and if an NFR needs to be defined I support it. I note the following statement in the Standards though which makes me think if this is happening in the wild it is non-compliant already:

Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page

[nils-work]

This issue was discussed in the first call of Maintenance Iteration 15.

Participants concluded that it may be sensible to defer this proposal, preferring to:

• wait for data that may become available as a result of Decision Proposal 288 - Non-Functional Requirements Revision, to establish whether this is a common area of concern, and
• focus on general authentication uplift, rather than modifying the existing OTP approach.

[biza-io]

Specifying an NFR for guaranteed delivery of an OTP is not technically possibly for a myriad of reasons including SMS delivery delays and email server protections etc.

Biza believes a more effective mechanism for resolving this issue is contained within the proposal for NFR and Metrics uplift in DP288 which incorporates a pre authentication and post authentication checkpoint. With this data the DSB/Regulator could contact Holders which appear to have low progression to post authentication state to identify the reasoning for why this might be happening.

[jimbasiq]

I agree this is hard due to the reliance on external systems or services.

Perhaps we could have an aggregate metric reported on the volume and % of Consumers who are hitting the "Resend OTP" per DH?