1. Introduction
Strong Customer Authentication (SCA) is a generic term used to describe multi-factor user authentication supported by proofs-of-authentication, which came to prominence in the open banking due to its inclusion as a Regulatory Technical Standard (RTS) under PSD2. 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:
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 categorised 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 authorised by the User.
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, SCA has different implementations across the EU, and the dynamic linking requirement is manifested in a number of different ways. Bringing together a best practice based on existing implementations is therefore difficult. However, and despite the variance between EU countries, the spirit of the RTS can be transposed into multiple, relevant protocols for User authentication that provide an implementation of multi-factor authentication and proofs-of-authentication.
The protocols and implementations included in this page can help provide multi-factor authentication and proofs-of-authentication for participants in an open finance ecosystem. This page is provided as guidance for ecosystem participants, to help them make informed choices in extending authentication options as open finance is extended.
2. FIDO2
FIDO2 is a suite of protocols designed to offer strong proofs-of-authentication while eliminating the reliance on passwords.
The diagram below provides the key actors:
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, through the Web Authentication (Webauthn) API, dynamic linking requirements. One of the inputs to the invoking the Webauthn API The response to a request for User authentication, known as an Authentication Assertion, 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 a widespread
The following are links to the relevant information on FIDO2:
FIDO Alliance FIDO2 Homepage: https://fidoalliance.org/specifications/
Dynamic Linking white paper: https://fidoalliance.org/fido-standards-meet-psd2-sca-requirements/
3. Passkeys
Passkeys are a cross-browser, roaming implementation of FIDO2 credentials, which has been developed by the FIDO Alliance with industry protagonists like Apple and Google.
As Passkeys is a FIDO2 implementation it offer the same benefits as the FIDO2 suite of protocols, but adds the ability to synchronise keys between devices and retrieve keys from backup in the case of device loss or failure.
SCA is provided in this context by FIDO2, as Passkey is a FIDO2 implementation.
The following are links to relevant information on Passkeys:
FIDO Alliance Passkeys Homepage: https://fidoalliance.org/passkeys/
4. OpenID for Verifiable Credentials
The following are links to relevant information on OpenID for Verifiable Credentials:
Implementers Draft for Credential Issuance: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html
Implementers Draft for Verifiable Presentations: https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html
5. Secure Payment Confirmation (SPC)
5.1 Description
5.2 Links
SPC Homepage: https://www.w3.org/TR/secure-payment-confirmation/