ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.

41 stars 9 forks source link

OTP NFR added to the Consumer Data Standards #554

Open jimbasiq opened 1 year ago

jimbasiq commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.