Overview
In 2015, the European Banking Authority issued the revised version of its Payment Services Directive, commonly known as PSD2. Alongside the directive, the EBA produced a set of Regulatory Technical Standards (RTS) on strong customer authentication and secure communication.
The RTS provides overall goals for authentication and secure communication, but are deliberately non-specific about how to meet those goals. So, if you are hoping to build a compliant platform based solely on the RTS document, then you’re out of luck.
For those of us who do have to build compliant systems, one area of hot debate is the concept of dynamic linking. This applies to the authentication of remote payment transactions, the idea being that the transaction details are bound to the authentication process; or, in the words of the RTS, “ensuring that the elements (for example, the authentication factors) dynamically link the transaction to an amount and a payee specified by the payer when initiating the transaction.”
What does dynamic linking actually mean?
Good question.
Most of the details are provided in Article 5 of the RTS. The three key criteria are as follows:
- The payer is made aware of the amount of the payment transaction and of the payee.
- The authentication code generated shall be specific to the amount of the payment transaction, and the payee agreed to by the payer when initiating the transaction.
- The authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the payee agreed to by the payer. Any change to the amount or the payee shall result in the invalidation of the authentication code generated.
“Authentication code” is deliberately vague—the RTS document states the following:
To remain technologically neutral these technical standards should not require a specific technology for the implementation of authentication codes. Therefore authentication codes should be based on solutions such as generating and validating one-time passwords, digital signatures or other cryptographically underpinned validity assertions using keys and/or cryptographic material stored in the authentication elements, as long as the security requirements are fulfilled.
There’s a big clue here: “Any change to the amount or the payee shall result in the invalidation of the authentication code generated.” In the real world, this points to a digital signature of the transaction details, or an OTP generated from input data including the transaction details (which is kind of the same thing).
Identity is not enough
In order to provide higher assurance for payments (or setting up payees etc), service providers have traditionally re-authenticated the end user, often with an additional factor of authentication; for example, step-up authentication.
This does not on its own provide dynamic linking. We are confident that we have the right person in front of us at the time of the transaction, but we are not sure that they are making the same payment request that we see. What we want to do is to authenticate both the user’s identity and the transaction request— who and what—to make sure that nothing has been altered along the way.
Step forward, CIBA
What we need is a way to deliver transaction details securely to an end user, have the user consent to those details, and strongly authenticate the whole process. The outcome needs to be an authentication code which can be verified against the original request, along with the user’s identity.
With client-initiated backchannel authentication (CIBA), we have the delivery channel we need for the end to end process. Put simply, CIBA is a new grant type for OpenID Connect tokens.
An OAuth2 client, such as a payment service provider, can connect to an authorization server, and ask for a payment request (or any other kind of request for that matter) to be verified by the end user.
The authorization server handles the communication with the user, and drives the authentication process. Once the authentication process is complete, the authorization server returns a token verifying the user’s identity.
The CIBA flow
The first step is to send a CIBA request to the authorisation server. This request contains two key pieces of information:
- A unique user identifier for the end user
- The details of the transaction request
The authorisation server contacts the user so that she can view and approve the request on her authentication device. For example, using the ForgeRock® Authenticator app, she will see the following (in real life you would embed this function within your own app):
Once the end user has approved the request, the authorisation server sends a positive response back to the calling application (the OAuth2 client), along with the user’s details in the form of an OIDC token. The client is also given an access token to request more information if required.
How is this dynamic linking?
In the above flow, the end user acknowledges the transaction via the authenticator app, using a registered key.
The outcome of this process is a digital signature, which is verified within ForgeRock® Access Management. Any change to the payload will invalidate the signature, in line with PSD2 dynamic linking requirements.
The authenticator app ensures that the end user authenticated herself with two of the elements required for strong customer authentication under PSD2:
- Possession: We have proved that the user is in possession of the registered mobile device, because the unique secret key only exists on that device.
- Inherence: (through Touch ID) or Knowledge (if there was fallback from touch ID to device PIN)
Conclusion
CIBA does not by itself provide dynamic linking. It is however an important part of the puzzle, providing an open standards based channel to an end user device for digital signature.
In the next article, we’ll see in more detail how to set up a CIBA enabled payment flow using ForgeRock Access Management together with ForgeRock Authenticator.