...
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 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 authorised authorized by the User (Article 5).
SCA is therefore very strongly allied to multi-factor authentication, and specifically outlines the acceptable factors, namely:
...
This page is therefore provided as guidance for ecosystem participants, to help make standardised 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.
...
Principle | Rationale | |
|---|---|---|
| 1 | User authentication is implemented using MFA, where two factors are required to authenticate a given User | MFA is an existing best practice for User authentication that is prevalent in most open banking implementations. |
| 2 | 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 ecosystem. |
| 3 | 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. |
| 4 | 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 reauthorization of a long-term consent. Establishing this link provides accurate access controls established as a consequence of the User authentication operation and subsequent authorisation authorization undertaken by the User. |
| 5 | Attestation 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. |
| 6 | Open standards are leveraged wherever possible | Using open standards is a recognised recognized means to create an interoperable and extensible ecosystem. Organisation Organization should look to leverage the standards and implementations described in the Emerging Standards section below. |
...
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 organisational organizational controls that govern mobile and internet banking.
Control | Rationale | |
|---|---|---|
| 1 | Mobile apps that are used to authenticate Users are installed from an authorised authorized and certified source |
|
| 2 | Mobile apps that are used to authenticate Users verify they are installed on a mobile operating system version for which they are approved |
|
| 3 | A given installation of an application that performs User authentication is correlated to the signature of device on which it is installed |
|
| 4 | 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 |
|
| 5 | Private keys created on a device for purposes of authentication are stored in the device security module |
|
| 6 | Private keys are represented by their corresponding public key or certificate, which can be published for use by relying parties |
|
| 7 | Use a biometric gesture (digit, face) as an authentication factor |
|
| 8 | A given authentication operation accepts an input parameter that uniquely links a given authentication operation to a given consent or consent signature |
|
| 9 | The identifier used to link to a given consent or consent signature is validated before a User authentication operation is initiated |
|
| 10 | A given User authentication operation is asserted using a complex object that describes the conditions of the User authentication operation |
|
| 11 | The assertion of a given User authentication operation is signed using the private key available in the device security module |
|
| 12 | 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 |
|
| 13 | Signing of the assertion of a given User authentication operation is consistent with the FAPI 2.0 Security Profile |
|
| 14 | Apps must verify the identity of external services on which they have a dependency for User authentication operations |
|
| 15 | TPPs must safeguard against installation of their apps on jailbroken devices and prohibiting initiating redirects for Authentication and Authorization when installed on a jailbroken device. |
|
| 16 | TPPs must not allow installation or usage of their apps from within sanctioned countries, including but not limited to initiating redirects for Authentication and Authorization. |
|
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 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 Authorisation Authorization Code flow using a custom claim or a standard argument like login_hint.
...
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 organisationsorganizations, 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 synchronise 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 synchronisationsynchronization, which improves user experience.
...
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 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 authorisation 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 standardisedstandardized. Standards and reference implementations for the EU Digital Wallet are currently being built.
...