User authentication is implemented using multi-factor authentication where two factors are required to authenticate a given User

Multi-factor authentication MFA is an existing best practice for User authentication that is prevalent in most open banking implementations.

Multi-factor authentication MFA is based on the attributes of Inherence, Knowledge and Possession

Inherence, Knowledge and Possession are established factors and can be readily supported in the majority of implementations of multi-factor authentication.

A given User authentication operation is uniquely identified

An audit trail should be provided to link a User authentication operation with an action in the open finance ecosystem. Establishing this link will provide solid foundations for activities such as fraud prevention and dispute resolution.

A given User authentication operation is correlated with a given data sharing or service initiation consent

A given User authentication operation should be linked to a consent that has been agreed between a TPP and the User, either as a first-time consent or reauthorisation of a long-term consent. Establishing this link provides accurate access controls established as a consequence of the User authentication operation and subsequent authorisation undertaken by the User.

Open standards are preferred to a bespoke implementationAttestation of User authentication is available as a cryptographically-verifiable proof-of-authentication

A given User authentication operation should be linked to a private key unique to the user. The presentation of a cryptographic signature generated using the private key can be verified using a corresponding public key that can be access by a relying party who depends on the User authentication operation to provide access to services or data.

Open standards are leveraged wherever possible

Using open standards is a recognised means to create an interoperable and extensible ecosystem. Organisation should look to leverage the standards and implementations described in the Emerging Standards section below.

Mobile apps that are used to authenticate Users are installed from an authorised and certified source

• Provides an authorised source for an app design to authenticate the User

• Provides a means for an app to be installed from a source trusted by the User

Mobile apps that are used to authenticate Users verify they are installed on a mobile operating system version for which they are approved

• Ensures that the mobile app works as expected based on the functionality available on the mobile operating system

• Lowers the risk of inadvertent leaking of User information based on unexpected results

A given installation of a mobile app an application that performs User authentication is correlated to the signature of mobile device on which it is installed

• Ensures that when a User authentication operation is elicited by an application there is a clear binding between a given installation and a given device, providing assurance of the provenance of a given User authentication operation

A given User is correlated to a private key, used for the purposes of User authentication, which in turn is correlated to a given device

• Provides binding between a given device and the private key that represents the User

Private keys created on a mobile device for purposes of authentication are stored in the device security module

A biometric gesture is used to authenticate the User

A given authentication operation provides proofs-of-authentication that can be verified by a relying party based on a shared public key

• Reflects OWASP mobile app best practices

• Accepted industry standard

Private keys are represented by their corresponding public key or certificate, which can be published for use by relying parties

• Allows a relying party to verified any cryptographically-signed assertions provided from a given device

Use a biometric gesture (digit, face) as an authentication factor

• Provides a strong proof of user identity when coupled with other controls

A given authentication operation accepts an input parameter that uniquely links a given authentication operation to a given consent or consent signature

• Provides a nonce that increases entropy in the cryptographic signing operation

• Allows a signature to be indelibly linked to a given consent object

The identifier used to link to a given consent or consent signature is validated before a User authentication operation is initiated

• Ensure that user “intent” - where a first-time consent is being sought - is valid

• Verify that an invalid consent reference has not been injected

A given User authentication operation is asserted using a complex object that describes the conditions of the User authentication operation

• Provides metadata about a given User authentication operation to relying parties, for the purposes of verifying the operation

The assertion of a given User authentication operation is signed using the private key available in the device security module

• Provides a cryptographically-based assertion of a given User authentication operation

• Allows the assertion of a User authentication operation to be verified by relying parties, where supported by a suitable public key

Signing of the assertion of a given User authentication operation is completed using an appropriate function or method available on the device that provides signing access

• Prevents exposing the private key to untrusted components

• Ensures the key does not leave the secure storage area on the device

Apps must verify the identity of external services on which they have a dependency for User authentication operations

• Lowers the risk of allowing miscreants to misdirect the authentication flow, where a User must be redirected or handed-off to an external service once MFA has taken place

• Allows mobile app publishers to take advantage of approaches like certificate pinning to help ensure external services are correctly identified