| Expand | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
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 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 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 (Article 5).
...
Bringing together a best practice based on existing implementations across open banking markets is therefore difficult to achieve. 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 , 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. At the time of writing the options considered are:
FIDO2
Passkeys
OpenID for Verifiable Credentials
Secure Payment Confirmation
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 . This can coupled with relevant technical controls that provide guidance on specific implementation approaches to ensure that SCA is performed in a sufficiently secure context. Emerging technologies and standards are also described and how they can be leveraged in implementing SCA.
This page is therefore provided as guidance for ecosystem participants, to help make informed standardised 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
Principle | Definition | Notes | |
|---|---|---|---|
| 1 | |||
| 2 |
3. Controls
Control | Description | Principles | |
|---|---|---|---|
| 1 | Mobile apps that are used to authenticate Users must be installed from an authorised and certified source | ||
| 2 | Private keys created on a mobile device for purposes of authentication must be stored in the device security module | ||
| 3 | A given authentication operation must provide proofs-of-authentication that can be verified by a relying party based on a shared public key | ||
| 4 | A given authentication operation must accept an input parameter that uniquely links a given authentication operation to a given consent or consent signature |
3. Emerging Standards
At the time of writing the standards and technologies considered are if the context of this page are:
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 FAPI, as the Assertion can be carried in Authorisation Code flow using a custom claim or a standard argument like login_hint.
...
FIDO Alliance FIDO2 Homepage: https://fidoalliance.org/specifications/
Dynamic Linking white paper: https://fidoalliance.org/fido-standards-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 organisations, however, and both hardware and software vendors are implementing support as a Webauthn Provider or Webauthn Relying Party.
...
FIDO Alliance Passkeys Homepage: https://fidoalliance.org/passkeys/
...
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 authorise 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.
...
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
Overview of issuance process (by Curity): https://curity.io/resources/learn/verifiable-credentials-issuance/
Reference Wallet implementations for the EU: https://github.com/eu-digital-identity-wallet
...
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.
...