Quali-Sign
	Specialists in mobile apps for eID and Strong Customer Authentication

Features > SCA Procedure

What is Strong Customer Authentication?
◆	Article 4(30) of the PSD2 Directive: ‘strong customer authentication’ means an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.
◆	In our approach, SCA involves the creation of an eIDAS Advanced Electronic Signature (AdES). The possession element takes the form of a cryptographic asymmetric private key, residing in the Separated Secure Execution Enviroment of a physical device (e.g. a smartphone). The private key is activated using the biometric sensor on the device (inheritance) and/or by supplying a PIN (knowledge).

Our eID procedure always creates SCA Proof.
◆	Whilst an eID can have many uses, these actions can largely be categorised as either Authentication or Authorisation. Examples of Authentication include opening a hotel room door or logging into a web site. Examples of Authorisation include signing a contract or approving a payment.
◆	In our approach, regardless of the eID action being performed, the outcome is always the generation of independently verifiable SCA proof. This is proof that an Identity Consumer can verify (both online and offline) and then subsequently use to prove to others.

With a comprehensive audit trail attached.
◆	The audit trail identifies the requesting party (always a certified Identity Consumer) and provides context and clarity over the nature of their request.
◆	Where an eID is being used for Authorisation, best practice requires the audit trail to include Proof Of Creation. This identifies who originally created the data and provides evidence that it has not be changed since it was created.
◆	It is crucial that the audit trail is dynamically linked to the proof. If elements of the audit trail are invalidated, this must also invalidate the proof. In our approach, the audit trail information is bound to the proof via its inclusion in the AdES.

Authorisation requires full visibility. Partial visibility means data is being withheld.
◆	Whenever a user is being asked to authorise data, this data must be available for them to review before they provide their approval. Data can be displayed within the eID app (e.g. a payment) or can be displayed externally (e.g. the text of a contract).
◆	Where data is displayed internally within the eID app, the end-to-end SCA procedure is under the control of the eID provider. This is especially important with respect to payments (see Article 5 of PSD2 RTS on SCA and CSC) where the display of the amount and payee(s) is an integral part of the SCA procedure.
◆	Where structured data is displayed within our eID app (as is the case for payments), we ensure that as well as summary information, the user can (if they choose) review every element of the payment. It is an important principle that no data element is hidden.
◆	As well as approving single payments, users can also approve bulk payments within our app. For bulk payments, the minimum (RTS) requirement is to allow the user to review the total amount and every payee (if they so wish). In our solution, every element of every transaction is accessible for the user to review.
◆	It should be noted that the action of authorising a payment enables the bank to shift the liability onto the payer, in the event of fraud. It is clearly impractical for a user to review every creditor in a bulk payment order containing thousands of transactions. Here the Proof Of Creation becomes essential to give the user additional comfort in order to provide their approval.

Our eID app supports multiple flavours of SCA.
◆	Our implementation of the Decoupled SCA procedure involves the eID provider (e.g. a bank) alerting the user that they have a new Order (e.g. payment request) to approve. This is downloaded to and then displayed within the app for the user to review. Multi-user approvals are also supported within this procedure.
◆	Our implementation of the Embedded SCA procedure adopts (proposed) open interoperability standards to enable a direct integration (via an internet or proximity connection) between the eID app and an Identity Consumer (e.g. a Third Party Provider, TPP). In the case of payments, this enables the TPP to attach the SCA proof to a payment request before transmitting it to the bank.
◆	For both Decoupled and Embedded procedures, we also support App-to-App Redirection. This enables another app on the same device to launch the eID app. Once SCA is performed, the user is handed back.
◆	Our approach enables the same user SCA credentials to be shared across the multiple flavours of SCA.