Alternative mechanisms for OTP

[NeilSansomeMBL]

Description

As part of our CDR implementation, we support our customers authenticating through our Macquarie Authenticator App utilising a One-Time Password (OTP). This streamlines the authentication process by submitting the OTP automatically rather than requiring manual entry. For customers who have not installed the Macquarie Authenticator, the OTP is distributed via SMS and manually entered.

The Authenticator process uses the same OTP authentication service that we offer to customers who have not installed the Authenticator (SMS) but automatically submits it when the client confirms their intention to begin the authorisation process. It is at our view that this is within the intent of the requirements set out for the consent model and consistent with the use of an OTP.

In summary, it is our view that by automating the OTP via the Authenticator, our implementation is:

• consistent with the use of an OTP for authentication,
• an improved customer experience,
• more secure than an SMS-based OTP (which could be ported), and
• does not impact the CDR ecosystem as this is an existing app that our customers use everyday to manage their banking security.

Area Affected

Security Profile – Authentication Flows

Change Proposed

Rephrase the below term to allow for the automated distribution of the one-time password on a customer’s behalf via a secure channel.

Current: 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

Proposed change: Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter or is entered on behalf of the customer into the redirected page.

[NeilSansomeMBL]

For more details, please see attached Sequence Diagram.

[JohnHarrison-Truelayer]

We are supportive of this change.

[ShaneDoolanAdatree]

Adatree is also supportive of this change.

[CDR-API-Stream]

A Decision Proposal is required to consider alternative mechanisms for OTP, #91 DSB Item - Consider alternative mechanisms for OTP has been added to DSBs future-plan backlog.

[joshuanicholson]

As an ADR, we fully support alternate methods like Mac Bank have suggested. The feedback from the current implementation of OTP mechanisms is there is significant variance across the different DHs. While the outcome of different methods is essentially the same, there are a couple of DHs that push to the banking app on the consumer's device, and these DHs have a significantly better user experience, leading to quicker consents, less friction, fewer abandoned consents, more trustworthy and 'appearance' of high security (I appreciate some people could argue the validity of this last point - but from a consumer perspective, an in-app push are known & expected)

[CDR-API-Stream]

Closing this issue as it will be considered as a Decision Proposal, see comment above.