With financial services providers anticipating the implementation of PSD2 regulations in Europe next year, The Paypers invited us to sit down with Netcetera and the Aite Group for a webinar last fall. 

The full discussion was very rewarding and both the opportunities and challenges of compliance were discussed in detail. If you are interested, you can see the full recording here.

Three central themes emerged from the questions that were asked during the event and we wanted to take a moment to go into a little more detail about Delegated Authentication, 3DS2, FIDO Authentication and the path to implementation.

Delegated Authentication:

We should start by referring you to the most recent webinar that Netcetera offered in early December: Simplifying the Checkout Experience with 3ds SDK and Delegated Authentication. In it, they go into a deeper discussion on what delegated authentication is and how it is performed. 

It is important to realize that delegated authentication is new. The specifications are brand new and certification programs on how delegated authentication should be performed and whether or not it is “compliant” are just being deployed. Within the next year, all large merchants will be looking at delegated authentication and finding ways to implement it. 

Delegated authentication has the potential to shift liability for chargebacks from the merchant to the card issuer. However, there are two flavors of delegated authentication. In the first, weaker case, the merchant simply tells the issuer that “Yes, I have authenticated this user”. The merchant provides no proof that they are compliant with the specifications of strong customer authentication for this transaction. This flavor does not shift the liability. However, if the merchant also provides proof with their attestation – for example, the “FIDO blob” – then the liability for the chargeback shifts to the issuer rather than the merchant. 

While delegated authentication is in its infancy, there is no need to wait to integrate strong customer authentication into your customers process flow. After all, the customer will still need to authenticate for other purposes – sign in, add a new card, change shipping address, for example. The most foresighted of merchants are implementing SCA solutions now that can integrate into 3DS2 and are capable of being used for delegated authentication even while the details are being worked out by the payment networks and operators. 

3DS2

Initially deployed by Visa as “Verified by Visa” and then “Visa Secure”, 3DS has been adopted by Mastercard, American Express and other major card issuers. This protocol connects merchants, card networks, and financial institutions in order to verify transactions and share data. Additional steps are integrated to help protect cardholders and merchants. 

In the early days of E-Commerce, 3DS1 was deployed and quickly became known as a “conversion killer” due to the level of friction it introduced into the transaction process. 3DS2 was specifically designed to reduce friction while meeting strong customer authentication requirements. 

We have worked closely with Mastercard to design what is affectionately known as the “FIDO blob” that can be inserted into the 3DS rails for inclusion into a payment approval by a card issuer. From the customer’s point of view, enrollment into either 3DS2 or FIDO authentication will be fairly specific to the issuer or merchant (those we call the “Relying Parties”). While this enrollment process is related to authentication, it actually falls into the category of ID proofing. 

Every relying party has a process for granting and resetting identity credentials – e.g. usernames and passwords. Usually, this process includes some sort of ID proofing such as an SMS message with a one-time passcode or using a service such as Jumio or OnFido.  Nok Nok has integrated an API that provides an easy combination of whatever ID proofing approach the relying party has with our authentication solution. We have worked very closely with many multinational companies to ensure that the customer flow for FIDO registration is as easy and frictionless as possible. Once the device is registered, any information returned from an authentication challenge can be inserted into the 3DS rails for payment approval by the issuer. 

Most issuers are ready for 3DS2 but many merchants are not. A large share of transactions are still using 3DS1 (and thereby killing conversions) or no 3DS at all. With the need for strong customer authentication, now is the time to implement such technologies to fully integrate the checkout process with the best current technology.

FIDO Authentication

The power inherent in FIDO Authentication is its versatility. FIDO-certified authentication allows for a wide variety of biometric options to confirm identity. However, the design specifications of FIDO require that a relying party does not store biometric templates. This raises the question: “How does the merchant know my biometric belongs to me?”

At the device registration stage, a relying party determines that a device and authenticator is in the hands of the client to whom the account is registered. Each relying party – having different levels of risk tolerance, anti-fraud requirements, or levels of access to sensitive data – may deploy different methods of determining this fact. Upon registration, the biometric template is stored on the device while a cryptographic key pair is registered with the relying party.  The relying party stores the public key in their server while the private key is stored on the customer’s device – preferably within secure silicon like a trusted execution environment (TEE). The authenticator (i.e. fingerprint scanner) will match a new scan with the template and “unlock” the private key to answer a challenge from the relying party – thereby proving that your biometric belongs to you. 

Importantly, this prevents a relying party – such as a merchant – from assuming the risk of holding biometric templates for all of their customers on a centrally stored database. Such vulnerabilities have led to fiascos such as the breach Aadhaar, India’s biometric identity system. Additionally, in the European Union, GDPR becomes a potential issue for storing any personally identifying information – such as a biometric template.

Behavioral biometrics are an intriguing path of technology that could make silent authentication truly widespread. The state of the art – however – is that most solutions store the behavioral template on central servers – violating a key tenet of the FIDO protocols. That being said – there have been discussions between key members of FIDO and providers of behavioral biometric technology that could lead to eventually including that modality in the future. 

Implementing Solutions

We all hope for a better, brighter future with friction-free, highly secure payments – but how easy will it be for traditional issuers and merchants to adopt or implement these schemes? Fortunately, quite easy. From a technical perspective, the industry has done a great deal to facilitate adoption of FIDO and 3DS2. Many global banks have already worked with Nok Nok to deploy FIDO for their login and are expanding their usage to other areas such as transaction confirmation. 

Card networks are leading the way regarding 3DS working on schemes that will help issuers, acquirers, PSPs and merchants to participate and adopt the technology quickly and efficiently. The specific method for inserting the “FIDO blob” into the 3DS rails is already defined in the upcoming 3DS 2.3 specification and we are developing multiple systems with our partners – such as Netcetera – to deliver this capability. 

The take-away is that, while some worry that PSD2 will be the return of the “conversion killer”, we have developed technology that will prove just the opposite. Rather than adding friction to the checkout process, it is now possible to see a process so smooth that the customers don’t even notice they are authenticating. We have done it before with customers at T-Mobile. We look forward to bringing this technology to you.