The PSD2 - Directive and Distributed Authentication

PSD2 breaks up the ways in which banks do their business, by forcing them to open up their APIs. By doing so, PSD2 challenges the way in which data was traditionally secured in banks.

In this article, we will have a deeper look at the aspect of authentication in the context of PSD2. We will first categorize the authentication challenges immanent to distributed systems. Then, building on NIST’s authentication reference model, we suggest an extended model that caters to the challenges in a distributed context. With this distributed authentication model, we want to provide a common language for the context, and a common understanding of the dimensions of the value flow in such composite systems. We want to be able to most accurately describe the relay of the user's identity through the various atomic services (the individual services which compose a composite service).

PSD2 - What is New?

The FinTech segment is a rapidly growing industry with potential disruptive impact on today's finance market. Legislation like the EU's Payment Service Directive PSD2 (2007/64/EC, 2nd amendment) is pushing banks to open up their APIs, and thus pave the way for much more complex, yet more effective, composite services, which are generated across boundaries of technical applications and domains as well as across legal entities.

Such new concepts imply lots of potential for enhanced customer benefit and user experience. However, they bring along a plethora of security challenges.

Authentication and Digital Identity

Let us first look at the relation of authentication and digital identity in the context of composite services.

Authentication is the act of verifying a person’s claimed digital identity, based on one or more factors of evidence (knowledge, ownership or inherent factors).

The digital identity of a person is based on validated attributes such as name, location, role as an employee, or age. Enrolment of a person into a digital identity is a complex process.

Composite and Distributed Services

PSD2 breaks up the classical monolithic payment service approach in banking. Services become composite, meaning, they cover two or more atomic services (or application), that are orchestrated into a new, more complex service. Such a composite service may be perceived by the user as one single service, as the user-interface normally reduces service complexity at the service’s front-end and does not indicate the complex service interaction in the background.

To take account for the fact that these composite services may be physically distributed across several domains, we also use the word “distributed service”.

Challenges

In the following section, we will try to categorize challenges that have a direct impact on the way authentication needs to be performed or implemented. These challenges should help us to subsequently develop suitable authentication concepts respectively, and verify their completeness. The categories are not completely orthogonal, but may have interdependencies in order to:

• Perform distributed authentication in a correct, coherent way
• Hold enough identification data for ALL possible transactions in all available systems
• Provide the suitable level of authentication for ALL possible transactions in all available systems
• Respond to different levels of trust
• Respect laws
• Respect privacy

Perform distributed authentication in a correct, coherent way

In composite services as described in PSD2, we need to share identity across two dimensions:

• Identity federation - to be accomplished across domains
• Identity propagation - to be managed across applications within the same domain

Commonly, a federation across domains would also include legal entities. But applications within a domain may also include different legal entities, as done e.g., in Salesforce's application cloud "Force.com", where the deployment environment hosts applications of various operators.

The challenge in a distributed service context is to hand over authentication from one application to the next one respectively, to propagate authentication between a sequence (or a chain with parallel branches) of domains/companies. In most cases, it is not sufficient to simply confirm the identity but also to handover identity data (e.g., account information, birth date, etc) to facilitate the further continuation of the composite service.

This passing of identity data is not purely a unidirectional process. Dynamic information related to identity might require to be passed backwards. This may be inert information such as a change in account number, but it may also concern dynamic (urgent) information such as a security breach.

In such a dynamic context, the system architecture needs to have the right trade-off between data consistency, availability and partition tolerances (CAP Theorem). The guiding question is: How to replicate dynamic authentication data across several servers or applications, potentially owned by several owners?

Hold enough identification data for ALL possible transactions in all available systems

Different transactions may require different data. The stored digital identity needs to be able to respond to the data requirements of the most demanding service in the sequence. But do all other services need to be given access to this exhaustive set of data as well?

Provide the suitable level of authentication for ALL possible transactions in all available systems

The level of authentication may vary and needs to be defined based on the (ideal or monetary) value of the transaction handled within the composite service. Also factors like threat level play a role.

Respond to different levels of trust

Not only the data requirement may impact the set of data that is shared but also the level of trust in a service. For example, the payment for a downloaded song should not allow for receiving information on the user’s marital status.

Respect laws

A distributed service might cover several areas of jurisdiction. The European Community is harmonizing the underlying laws of their member states. However, the simple hosting or backup outside that area of jurisdiction (e.g., in the USA) might cause a legal conflict.

Respect privacy

Scandals at Facebook or Yahoo indicate the possible impact of not properly defined or secured privacy terms. The sharing of private information between many potentially unknown agents makes privacy an important and highly critical aspect.

The classical Enrollment and Authentication Process

The American National Institute of Standards and Technology (NIST) has outlined a quite generic digital authentication model, which can be used as a basic explanation model for the classical authentication process, regardless of the geographical region or area of jurisdiction. We would like to first introduce this classical approach, and then see how it applies to distributed services in the context of PSD2.

Source: NIST Authentication Guideline (2016)

In the NIST model, an individual (applicant) applies to a credential service provider (CSP) and thus initiates the enrolment process. Once the CSP has successfully proven the applicant’s identity, he or she becomes a “subscriber”, and an authenticator (e.g., token) as well as a corresponding credential, such as a username, are established between the CSP and the applicant (now owning the the role of the subscriber).

The CSP has the task of maintaining the credential including its status and all enrolment data over the whole lifetime of the credential. The subscriber needs to maintain the authenticator(s).

This first part of the NIST reference model is applied in any enrollment process, where subsequent authentication is required, e.g., when a bank account is created or when a person signs up in an e-government process.

Once the applicant has become a “subscriber”, he or she can perform online transactions within an authenticated session, conducted with a relying party.

In such a transaction, the person holds the role of a claimant, proving to a verifier, the possession of one or more authenticators. A verifier and relying party might be the same or alternatively two independent entities. If a verifier and relying party are separate, the verifier has to provide assertion about the subscriber to the relying party. Subsequent to this assertion, the relying party may then initiate the transaction process.

In the following section, a typical classical monolithic payment sequence illustrates this reference process:

The account owner (“subscriber) wants to initiate a transaction.  He or she first needs to prove through one or more authenticators that he or she, who claims to be the account owner (“claimant”) actually is the person he claims to be (“subscriber).

The validation is done by a “verifier” who verifies the authenticators at the “credential service provider” and after validation gives authentication assertion to the transaction department of the bank (relying party). In many banks, the entities “verifier” and “credential service provider” may well be entities within the the bank.

Introducing a Reference Model for Distributed Authentication

Two approaches are feasible:

• Option A: Sequence of independent authenticated sessions
• Option B: One shared authenticated session

The first option offers establishing a separate security context to each relying party. This approach may be useful in some cases, the obvious one is the different nature of relying parties that support different security mechanisms.

The second option is more suitable to work with in environments such as homogeneous web services. Imagine a couple of web services (probably implemented on different platforms), but still supporting one set of RFCs (Remote Function Call).  

A sequence of independent authenticated sessions

Let’s imagine the case where we have to make a transaction going through the following parties:

1. An old IBM mainframe (in banking processing by mainframes still play an important role)
2. A modern web-service
3. A local database

Three relying entities, possibly three mechanisms of authentication, three network protocols. We have no choice except establishing three sessions.

In this case, a subscriber gets a some “context” from the Verifier and holds it as “application private memory”. Next, within each step of the transaction, the verifier passes the “context” to each relying party independently. This approach has several advantages:

1. The “context” may have some details specifically designated to each relying party - this increases a granularity and accuracy  
2. Also, the assertions from Verifier may have some significant details, important to each party.
3. Assertions could even be propagated via a reliable secured network. This  would further increase the achievable level of security.
4. It is less possible to compromise all authentication sessions at a time.
5. Sessions may be implemented differently - across applications or domain or both.

However, there is no advantage without disadvantages. The disadvantages would be:

1. Higher load on verifier - each forced to serve per-party requests
2. To  generate many types of “context”, the verifier logic may need to be more complex.

One Shared Authenticated Session

In the relatively new web-based world we use “web-services”, JSON or SOAP-based to do all the work. They are spread across the Internet. So we could use the single mechanism to perform authentication.

In this case we see the option of a subscriber including some “context” (or “token”)  in a transaction which is shared amid parties. The context is “self-evident” and could be easily verified without interaction with a Verifier. This approach has the following advantages:

• Simplicity - could be easily implemented
• Verifier is not loaded heavily and has simpler logic

The disadvantages will be:

• More time to verify “self-evident” context to reach required level of a security
• One point of failure - a compromised context will compromise all parties
• Poor granularity

The method is valid to authenticate a subscriber on semantically similar parties, where each party requires a similar set of attributes.

Non-Repudiation of Emission through eIDAS in Distributed Service Landscapes

Non-repudiation of emission (NRE) makes a link between the sender of a message and the specific content of the message. It can provide legal evidence that a person sent that particular message.

The NRE process includes:

• Encryption of data before being sent through the network
• The digital signature added proves that the message has been initiated by the client/user.

In the distributed services context, the challenge is that the message content evolves when passing from one service to the next. The evolving content needs to be authenticated in direct correlation with the sender.

If this process was carried out in compliance with eIDAS, the trust service provider would be able to provide sufficient evidence that the signature process and the evolution of the message throughout the composite service network was carried out by the user. Such evidence would be vital in case of litigation. Also a hacked or maliciously forged service would be prevented from being further treated in the service network as the signature would show an error.

Such a legal-technical framework is vital in such landscapes as PSD2. And it deserves further and technical consideration throughout the subsequent posts of this series of articles.

References and Further Reading

• Open Banking Europe Directory Services for PSD2 (10/2017), by PRETA

• PSD2 Directive - DIRECTIVE (EU) 2015/2366 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC (2015), by the European Parliament and the Council of the European Union.
• European Commission - Fact Sheet: Payment Services Directive (PSD2): Regulatory Technical Standards (RTS) enabling consumers to benefit from safer and more innovative electronic payments(11/2017), by the European Commission

• Regulatory Technical Standards on strong customer authentication and secure communication under PSD2 (2017), by the European Banking Authority EBA

• Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL amending Directive (EU) 2015/849 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing (2016), by the European Commission

• Selected articles on PSD2 (2016-today), by Gaurav Sharma, Guillaume Forget, Stefan Hansen, Peter Landrock, Peter Smirnoff, Michal Tabor and more

• Selected articles on Authentication (2014-today), by Heather Walker, Luis Balbas, Guillaume Forget, Jan Kjaersgaard, Dawn M. Turner and more

• Selected articles on Electronic Signing and Digital Signatures (2014-today), by Ashiq JA, Guillaume Forget, Jan Kjaersgaard , Peter Landrock, Torben Pedersen, Dawn M. Turner, Tricia Wittig and more
• REGULATION (EU) No 910/2014  on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (2014) by the European Parliament and the European Commission
• Recommendations for the Security of Internet Payments (Final Version) (2013), by the European Central Bank

 Image: Networks!, courtesy of Stephen D. Strowes, Flickr (CC BY-SA 2.0)