FIDO & PSD2: Solving the Strong Customer Authentication Challenge in Europe

All Rights Reserved | FIDO Alliance | Copyright 20181
FIDO & PSD2
SOLVING THE STRONG
CUSTOMER AUTHENTICATION
CHALLENGE IN EUROPE

2
AGENDA
PSD2 & Strong Customer Authentication
Requirements
Beyond Passwords with FIDO2
Bank Challenges & How FIDO Can Help

What is PSD2?
“An attempt to drive innovation through regulation”
• Regulates banks, payment services and other related financial services throughout the
European Union (EU) and European Economic Area (EEA)
• Goals:
• Increase competition and participation in financial services and payments by creating a path
for non-bank Third Party Providers (TPPs), including:
• Account Information Service Providers (AISPs) – entities that gather data on a user’s accounts and
present a unified view of finances, as well as offer advice
• Payment Initiation Service Providers (PISPs) – entities that don’t hold payment accounts for users,
but do allow users to make payments through them
• Give consumers non-bank choices in payments and financial services
• Improve consumer protection
3

Open
APIs
4
• New Access to Account mandate ➔ Open APIs
• New Strong Customer Authentication mandate
• New Third Party Provider (TPP) roles
Open
APIs
Open
APIs
Payment
execution
Open
APIs
Open
APIs
Open
APIs
Gives
consent
Payment Initiation
Service Provider (PISP)
Account Information
Service Provider (AISP)
PSD2 – Key Provisions

PSD2: Why Strong Customer
Authentication (SCA) Matters
If I am going to let a PISP or AISP
1. Access data from my bank account
2. Transfer money from my bank account
for a payment
My bank needs to:
• Authenticate me, and
• Know that I have authorized them
to do this
5

How this is often done today
“Credential Caching and Screen Scraping”
• AISP asks me for my username and password
• They store this – and log in with my credentials – sometimes several times a day
• They collect (aka “screen scrape”) all my account data to support their service
6

Screen Scraping – Some Issues
1. We tell people “never share your password”
• This requires people to trust a third party with their username and password
• Looks like a phishing attack
2. Passwords are fundamentally insecure
• Letting additional parties store passwords and other “shared secrets” raises risks
• Often breaks tools that protect the login process, including multi-factor
authentication (MFA) and behavior analytics
3. Issues with privacy and consent
• I think I am granting access to a small part of my account – but the TPP may get
access to all of it
• No way for a consumer to authorize access on a granular level
• GDPR concerns
7

Open
APIs
• Third parties can securely connect to a bank – no need to cache passwords
• Banks can share data directly with third parties – no screen scraping needed
• Banks can enable third party payment providers to initiate payments
• Customers can let their bank know they explicitly authorize access, and can
manage access on a granular level
Open
APIs
Open
APIs
Payment
execution
Open
APIs
Open
APIs
Open
APIs
Gives
consent
Payment Initiation
Service Provider (PISP)
Account Information
Service Provider (AISP)
How to address this: Open APIs

PSD2 SCA – Key Dates
• November 2017 – Final RTS published by EC
• September 2019 – Effective Date of RTS
• March 2019 - Banks must be ready 6 months before
effective date
• Banks must make interfaces available to TPPs for testing
http://ec.europa.eu/finance/docs/level-2-measures/psd2-rts-2017-7782_en.pdf
9

What the EBA Strong Customer
Authentication (SCA)rules require
Transactions require Multi-Factor
Authentication (MFA) - 2 of 3 elements:
▸ Something you know (password or PIN)
▸ Something you possess (phone, token,
card)
▸ Something you are (biometric)
Passw00rd
A “multi-purpose” device must protect the
independence of authentication elements
10

Requirements around user experience
EC concerns that banks would build bad APIs or
otherwise create obstacles to them accessing
consumer accounts – led to a ban on “obstacles”
to access.
▸ One example: a “redirect” model used with an
API “may” be an obstacle
▸ However, EC has been clear this was only an
example – and there may be redirect
implementations that do not cause obstacles
▸ If any obstacles exist – mandate to shift to a
“fall-back” option (a non-API interface) based
on caching customer’s banking passwords
11

Some implications
The “redirect model” is industry-accepted best practice for how a consumer can log in to one
account with a credential from another
▸ Based on proven standards (OAuth 2.0, OpenID Connect, FIDO)
▸ Dozens of vendors lined up behind it
▸ UK Open Banking Implementation Entity (OBIE) has already created standards based on redirect
The key: how to implement it with an excellent user experience
▸ FIDO implementations can streamline the authentication process – delivering strong customer
authentication more efficiently than other MFA tools.
12

Will we see PSD2 in the US?
• Unlikely that a regulation forces action
• But – Open Banking and Open Payments is happening
• The key is whether industry can figure it out themselves, rather than have
the government prescribe how to do it
13

Open Banking Standards in the US
https://www.fsisac.com/article/fs-isac-enables-safer-financial-data-sharing-api
Want a copy?
Reach out to
Eric Guerrino at
eguerrino@fsisac.com
14

Highlights of US FS-ISAC approach
• Standard APIs to enable secure third-party access
• When a consumer wishes to set up or add a bank, brokerage, or insurance account to a
third-party service, they will be seamlessly passed to a secure server at their financial
institution to begin the enrollment process.
• The consumer is presented with the financial institution’s consent page, where they
authorize which data or access privileges they wish to share with the financial application,
giving consumers control.
• After authenticating, the consumer is then seamlessly passed back to the financial
application. Data sharing between financial application servers and financial institution
servers is then done securely via a unique virtual token that identifies the consumer and
their respective accounts.
• Standards recommended: OAuth, OpenID Connect, FIDO
15

Details on SCA in the FS-ISAC Approach
• “OAuth 2.0 is the foundation for OpenID Connect 1.0. OpenID Connect 1.0 when used will promote secure user federation. Fast
IDentity Online (FIDO) 1.1 forms the design pattern for authenticating the consumer to allow maximum user agent interoperability
to better support public client agent applications. Use of these patterns should enable FIs to increase aggregator onboarding
velocity in a holistically secure and governable access model.”
• “All FIDO 1.1 security considerations should be observed and accounted for in the final implementations of the FIDO 1.1
specifications for both aggregators and FIs (where FIDO is used) to reduce vulnerabilities associated with this authentication
method.”
• “Use of Fast IDentity Online 1.1 (FIDO) Universal Authentication Framework (UAF) as an authentication method is recommended (in
the absence of a similarly capable FI solution) during the OAuth and OIDC sequence to support strong initial user authentication.
FIDO protocol challenge should be used by the FIDO server to activate the FIDO authentication framework and protocol sequence.
FIDO client registration may also be included as part of the authentication sequence where the customer’s user agent is FIDO-
capable (and FI policy provision allows), but not yet known to the FI’s FIDO server.”
• “FIDO Universal 2nd Factor (U2F) capability, which uses a hardware device to store identity tokens, might also be used to strongly
ensure and verify customer identity and presence executing high-risk operation(s). The FIDO client that implements U2F API must
be present on the user agent platform to respond to the FIDO server 2FA challenge and utilize the FIDO hardware device to retrieve
user identity keys registered with the FI FIDO server for aggregation API MFA / 2FA.”
*From “Control Considerations for Consumer Financial Account Aggregation Services” by the FS-ISAC
16

17
AGENDA
Requirements

The World Has a Password Problem
Data breaches in 2016
that involved weak,
default, or stolen
passwords1
81%
Phishing attacks were
successful in 20161 Breaches in 2017, a 45%
increase over 20162
1 IN 14
1,579
CLUMSY | HARD TO REMEMBER | NEED TO BE CHANGED ALL THE TIME

The Solution: Simpler *and* Stronger
open standards for
simpler, stronger
authentication
using public key
cryptography
Single Gesture
Phishing-resistant MFA
=
SECURITY
USABILITY
Poor Easy
WeakStrong

How Does FIDO Work?
AuthenticatorUser verification FIDO Authentication
Require user gesture
before private key can
be used
Challenge
(Signed) Response
Private key (handle)
per account Public key

Who is using FIDO today?
(Sample of deployments in production)

FIDO Specifications
FIDO UAF
FIDO U2F
(@FIDO)
CTAP
(@FIDO)
WebAuthn
(@W3C)
FIDO2 Project

WebAuthn Brings FIDO to the Web Browser
Participation
from all these
platform
providers
World Wide Web
Consortium (W3C)
developed
Web Authentication
(“WebAuthn”)
with FIDO Alliance
Contributions
Candidate
Recommendation
A new standard
JavaScript API
That works with all FIDO2
platforms & authenticators

FIDO “UNIVERSAL SERVER” Program
Ensures interoperability with all
FIDO Certified Authenticators
FIDO Universal Server

25
AGENDA
Requirements

26
BANK CHALLENGES WITH PSD2 IMPLEMENTATION
• Deployment of Strong Customer Authentication (SCA) to ALL of users
• Compliance
• With the Regulatory Technical Standards (RTS)
• With security
• With the General Data Protection Regulation (GDPR)
• The customer journey and the issue of “obstacles”

DEPLOYMENT CHALLENGE

28
BANKS HAVE TO PROVIDE SCA TO ALL OF THEIR USERS
Necessity to reach 100% users ➔ multiple devices may be necessary
Bank
App
FIDO Standards reduce the cost of
deploying multiple devices
FIDO server

29
BANK CAN USE AN ALREADY DEPLOYED FIDO DEVICE
Bank
App
FIDO server
Metadata
server
Device metadata
Public key
uploaded
Device
Attestation
Bank key pair can be
generated in an
existing FIDO device
Private key
securely stored
Bank can check that the FIDO
device is genuine
➔ Attestation mechanism
1
2
Bank can verify that the FIDO
device complies with its
security policy
➔ Verification of device
metadata (characteristics)
3

COMPLIANCE CHALLENGE

31
FIDO STANDARDS ARE FULLY IN LINE WITH THE RTS
• Based on multi-factor authentication
• Secure execution environments ranging from hardened
software to TEE to Secure Elements
• Strong focus on privacy and biometrics

32
FIDO HELPS COMPLY WITH GDPR
• FIDO’s principle of no shared secrets is in line with GDPR’s “Privacy by
Design”
• Bank keys (private & public) are generated in the authenticator
• Only public key is uploaded to bank’s server
• Local verification (of PIN, of biometric data)
• No hackable data base of authentication credentials

FIDO COMES WITH A CERTIFICATION PROGRAM
• It is unclear what the National Competent Authorities will define as a
compliant solution
➔ the FIDO certification program can help
• Functional certification
• Authenticator security certification, with the help of independent
accredited labs
• New biometrics certification

THE CUSTOMER JOURNEY AND THE
ISSUE OF “OBSTACLES”

FIDO SUPPORTS THE REDIRECTION MODEL
PISP
FIDO
device
ASPSP
Login
Pswd Go
Merchant MerchantMerchant
PISP
Bank 1
Bank 2
Bank 3
Select Bank
Approve
ASPSP
app
Example for payment initiation

36
FIDO SUPPORTS THE DECOUPLED MODEL
PISP
Merchant Merchant
Approve
Transaction
Merchant
PISP
Merchant
PISP
ASPSP
app
Approve
Transaction
ASPSP
app
FIDO
device

37
ADVANTAGES OF THE REDIRECTION/DECOUPLED MODEL
• Fastest way for a bank to implement SCA
• Re-uses the authentication for bank’s own services
• In line with current practices
• No dependence on other parties
• No impact on the Open APIs
• There is no need for APIs to support authentication in these models
• Some users will feel comfortable authenticating via
the bank’s interface
• Trust
• Familiarity
My Bank

ACCOUNT AGGREGATION CAN LEAD TO A
CUMBERSOME USER EXPERIENCE
ASPSP C
Login Go
AISP
AISP
ASPSP B
Login
Pswd Go
Confirm
ASPSP
app

39
FIDO FULLY FUNCTIONAL WITH FEDERATED IDENTITY
An interesting solution to cope with the multiple redirection issue
AISPAISP IDP
Authenticate
with your device
IDP
app
ASPSP A ASPSP B ASPSP C
AISP
IDP
authentication Access tokens
FIDO device

40
THE EMBEDDED MODEL, AS FIDO LOOKS AT IT
AISPAISP AISP
Authenticate with
your device
PISP
Approve
Transaction
Merchant MerchantPISP
Example for account aggregation
Example for payment initiation

41
FIDO HAS ENGAGED WITH API STANDARDISATION BODIES
• Open APIs must support challenge/response mechanisms
• ASPSPs must “white list” the TPPs
• ASPSPs must agree to the user verification step being handled by the
TPP application

42
KEY TAKEAWAYS
• FIDO standards: a good solution for any of the authentication models
• Security and Privacy by Design
• Meet all the RTS requirements
• Alignment with authorization frameworks
• FIDO standards maximize reach
• They support a large variety of devices
• FIDO standards: versatile and future proof
• Bank can support the redirection and decoupled models
• Bank can propose the embedded model to TPPs that integrate FIDO authenticators
in their solutions

FIDO & PSD2: Solving the Strong Customer Authentication Challenge in Europe

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FIDO & PSD2: Solving the Strong Customer Authentication Challenge in Europe

Similar to FIDO & PSD2: Solving the Strong Customer Authentication Challenge in Europe (20)

More from FIDO Alliance

More from FIDO Alliance (20)

Recently uploaded

Recently uploaded (20)

FIDO & PSD2: Solving the Strong Customer Authentication Challenge in Europe