1. Introduction

Strong Customer Authentication (SCA) is a generic term used to describe multi-factor user authentication (MFA) supported by proofs-of-authentication. SCA came to prominence in the open banking due to its inclusion as a Regulatory Technical Standard (RTS) under Payment Service Directive 2 (PSD2) in the European Union (EU). It sets the requirements for authenticating a Payment Services User - the account-holding customer who is making a payment - that must be adhered to in local law.

There are two key provisions that were heavily focused on in creating standards for open banking in the EU namely:

• An authentication code indicating permission to make a payment must be based on at least two authentication factors: “the authentication shall be based on two or more elements which are categorized as knowledge, possession and inherence and shall result in the generation of an authentication code.” (Article 4.1).

• The concept of “dynamic linking”, which requires that the the payee and amount are inputs to the creation of authentication codes that indicate proofs that payment has been authorized by the User (Article 5).

SCA is therefore very strongly allied to multi-factor authentication, and specifically outlines the acceptable factors, namely:

• Inherence: “Something you are” - a biometric credential indelibly linked to you.

• Knowledge: “Something you know” - a secret known to you and only you.

• Possession: “Something you have” - A device that can only be accessed and activated by you.

However, PSD2 is a directive and had to be interpreted in local law by different EU jurisdictions. SCA therefore has different implementations across the EU, and the dynamic linking requirement is manifested in a number of ways. The vast majority of implementations for open banking APIs involve the mobile banking app belonging to a bank, but there are two inherent limitations in this approach:

• Proofs-of-authentication: Invoking authentication through a biometric gesture on a given device results is an assertion at the mobile operating system level. This assertion is not, however, especially portable and provides proof only to the app invoking the request.

• Alternative SCA providers: Broadening the scope of available identity providers is more cumbersome as the bank is the de facto identity provider in the context of an authentication flow.

Bringing together a best practice based on existing implementations across open banking markets is difficult to achieve. However, and despite the variance between EU countries, best practices can be achieved based on:

• A principles-based approach, which will help guide implementers to incorporate the correct features that provide both multi-factor authentication and proofs-of-authentication.

• Relevant controls that provide guidance on specific implementation approaches to ensure that SCA is performed in a sufficiently secure context.

• A view of emerging technologies and standards that can be leveraged in implementing SCA.

This page is therefore provided as guidance for ecosystem participants, to help make standardized choices in extending authentication options as the adoption of open finance is extended in the market, with the goal of creating an extensible ecosystem for SCA.

2. Principles

The following are the principles on which the implementation of User authentication should be based.

3. Controls

The following controls should be applied when implementing User authentication functionality for use in the open finance ecosystem.

These controls are intended to be normative, but not exclusive. Other controls, such as the OWASP Mobile Top 10 should be considered, together with existing organizational controls that govern mobile and internet banking.

3. Emerging Standards

At the time of writing the standards and technologies considered to be consistent with the principles and controls above are as follows:

• FIDO2

• Passkeys

• OpenID for Verifiable Credentials

• Secure Payment Confirmation

Each is discussed in more detail in the sections below.

3.1 FIDO2

FIDO2 is a suite of protocols designed to offer strong proofs-of-authentication while eliminating the reliance on passwords. Unlike app-based biometric authentication it provides proofs-of-authentication based on providing an Authentication Assertion, which is an object signed by a private key resident on a given device. The object signature can be verified by using a corresponding public key, which is held by the Webauthn Relying Party following an enrolment ceremony. Authentication Assertions can also complement OpenID Connect and FAPI 2.0, as the Assertion can be carried in Authorization Code flow using a custom claim or a standard argument like login_hint.

The diagram below provides the key actors and their dependencies:

FIDO2 protocols are very widely supported on all devices that have come into the market recently, and the Web Authentication (Webauthn) API is supported in all major browsers. FIDO2 is often associated with and considered to be supportive of SCA, due to :

• Private key provisioned on device: FIDO2 protocols specify that a private key is provisioned on and never leaves an appropriate device (Possession).

• Interaction is generally through the device biometrics (Inherence).

• Fallback is allowed to a passcode or password (Knowledge).

FIDO2 also supports dynamic linking requirements. One of the inputs to the invoking the Webauthn API is a challenge that can be set by the Webauthn Relying Party and can include relevant arguments such payee details and amount, encoded as a string. The response to a request for User authentication can provide an authentication code. The FIDO Alliance has long asserted that FIDO2 standards can meet PSD2 requirements, but the standard have continued to evolve without, so far, widespread adoption in open banking. An extension of FIDO2, called Secure Payment Confirmation (SPC), is however already included in 3D Secure so their is some adoption in the banking and payments space.

The following are links to the relevant information on FIDO2:

• FIDO Alliance FIDO2 Homepage: User Authentication Specifications Overview - FIDO Alliance

• Dynamic Linking white paper: Deploy FIDO Standards to Meet PSD2 SCA Requirements

3.2 Passkeys

Passkeys are a cross-browser, roaming implementation of FIDO2 credentials, which has been developed by the FIDO Alliance in cooperation with industry protagonists like Apple and Google. Implementing Passkeys is not the preserve of these organizations, however, and both hardware and software vendors are implementing support as a Webauthn Provider or Webauthn Relying Party.

As Passkeys is a FIDO2 implementation it offer the same benefits as the FIDO2 suite of protocols, but adds the ability to synchronize keys between devices and retrieve keys from backup in the case of device loss or failure, a key critique of the out-of-the-box standards. SCA is provided in this context by FIDO2, as Passkey is a FIDO2 implementation.

The key point on Passkeys over a new FIDO2 implementation built from scratch is one of scale, due to the fact that existing providers are building out their support for the implementation and thus can readily support proofs-of-authentication in the market. There is also the point of backup, recovery, and synchronization, which improves user experience.

Building a trust framework using Passkeys is therefore, from a technical sense, more straightforward. The following are links to relevant information on Passkeys:

FIDO Alliance Passkeys Homepage: Passkeys - FIDO Alliance

3.3 OpenID for Verifiable Credentials

OpenID for Verifiable Credentials is a new protocol that extends OpenID to allow presentations of credentials on behalf of users. It allows multiple, limited scope credentials to be minted that can be used for specific use cases. Examples abound, including dedicated credentials for appliances, vehicles, or specific merchants, or combining several credentials to authorize access to a given resource, such a having both club membership and a payment credential to access premium features at the gym. It is one of the standard proposed to enable the EU Digital Wallet.

Credentials can be stored in a wallet, and tied to specific use cases. Credential issuance is built on OAuth 2.0, and can therefore complement the adoption of FAPI 2.0. A bootstrap process for credential issuance is required, which can rely on existing authentication and authorization flows, but once issued the credentials can be presented in the form of signed JSON Web Token (JWT) that can be verified. The important point here is that the JWT can contain presentation metadata, which can meet dynamic linking requirements.

Applying SCA in this context requires more development, however, as the mechanism for credential retrieval from a wallet has yet to be formally standardized. Standards and reference implementations for the EU Digital Wallet are currently being built.

The following are links to relevant information on OpenID for Verifiable Credentials:

• Implementers Draft for Credential Issuance: OpenID for Verifiable Credential Issuance - draft 13

• Implementers Draft for Verifiable Presentations: OpenID for Verifiable Presentations - draft 18

• Overview of issuance process (by Curity): Issue Verifiable Credentials using OpenID4VC

• Reference Wallet implementations for the EU: European Digital Identity

3.4 Secure Payment Confirmation

Secure Payment Confirmation (SPC) is an extension of Webauthn built for payments use cases. A Webauthn Relying Party can prompt for a Secure Payment Assertion, which incorporates a user journey that explicitly binds payment parameters with the resultant Assertion. As previously mentioned, SPC is already supported in 3D Secure.

As SPC is an extension of Webauthn it naturally supports SCA and was built specifically to incorporate dynamic linking support. It has not, however, been widely supported in Safari and may also be refactored to complement Passkeys more readily. It also only supports payments use cases, so will need to be complemented by native Webauthn assertions for data sharing requests.

The following are links to relevant information on SPC:

• SPC Homepage: Secure Payment Confirmation