One Time Password (OTP)

Customer authentication with multiple IDs

It is expected that a single piece of information is used to uniquely identify a customer. However, to determine a specific profile related to a customer ID, additional information could be requested.

When trying to distinguish different customers or profiles with the same ID, it is acceptable to ask the consumer to enter two pieces of data, for further identification.

For determining which mobile number to use for OTP, where there are multiple mobile numbers for a customer, it is a valid approach to request the mobile number, provided the supplied mobile number is validated against a number already on file for the customer.

It is clearly a security risk to use, for OTP, a number supplied by the customer without any validation.

Two Factor Authentication (2FA)

The delivery mechanism for the One Time Pin (OTP) is at the discretion of the Data Holder (DH) but it must align with existing and preferred channels for the customer and it must not introduce unwarranted friction into the authentication process.

2FA multiple channels

When multiple channels are involved, an additional authentication mechanism would add friction. Instead,  the use of the nominated 2FA mechanism to provide the OTP rather than giving two OTPs via two different channels is recommended.

Sending an OTP to an international phone numbers

OTPs do not have to be sent by SMS or by phone. The rules and standards do not specify SMS, but do require that the OTP be sent through a mechanism which MUST align to existing and preferred channels and MUST NOT introduce unwarranted friction into the authentication process. Otherwise the mechanism for sending the OTP is at the discreiton of the DH.

OTP expiry

It is at the discretion of the DH to select a reasonable expiry timeframe for an OTP. The DH should consider security posture and implementation implications when determining the expiry timeframe. 

Existing hardware tokens

The provided OTP must be used only for authentication for CDR-based sharing and must not be usable for the authorisation of other transactions or actions. The intent here is that a token provided to a customer for another purpose (for instance a payment authorisation) can not be leveraged for CDR consent. 

OTP retries

The Consumer Data Standards do not preclude multiple OTP retries, and are intentionally silent on how many retries to allow.

The CX Guidelines do not provide a guideline for the scenario where the consumer retries the OTP or requests a new OTP. The DSB recommends allowing the consumer to request another OTP at the OTP authentication step.

It is good practice to limit the number of failed retries before cancelling the request. Unlimited retries create a security vulnerability. How DHs deal with incorrect authentication details is at their discretion. DHs are expected to consider any identified phishing risks. The procedure should be in line with the Data Holder's existing security posture.

Future CX Guidelines may include an example for requesting another OTP.

Incorrect authentication 

How DHs deal with incorrect authentication details is at their discretion, which is expected to have regard for any identified phishing risks and be in line with the DH's existing security posture.

OTP sent to the email address used as customer Id

If the DH chooses to use an email address for the Customer ID, then given the potential threat of security breaches, the general DSB recommendation from a security perspective would be not to send the OTP to an email address.

Level of Assurance (LoA)

For read access operations, DHs should support LoA2. Some implementations of OTP using a secure authenticator may result in a LoA3. DHs should publish their supported LoAs using acr_values_supported which advertise what acr values an Accredited Data Recipient (ADR) can request. If the DH does not support LOA3 or cannot achieve LOA3, then the request should be rejected.

OTP must be presented in a web view

The standards currently do not support Security App or App2App redirect.