NextGenPSD2 interaction models

This section explains how Airlock protects interactions between the end-user, the TPP and the bank and shows how this can be achieved with the Airlock components.

The interactions can be classified in the following types. Details for each type can be found in the following sections.

Interaction	Description	Airlock concept
Bank API calls	All REST API calls from the TPP to the bank's REST services. Examples: Requests on REST resources /accounts, /payments, /consents.	One-Shot Authentication Flow (HTTP request authentication)
User consent	The end-user communicates directly with the bank in order to give the consent, that a TPP may access the end-user's bank account(s). The bank authenticates the end-user and asks for the required consents.	Redirect Authentication Flow

Bank API calls (interaction model)

In the following, we illustrate the interaction between the TPP and the bank using the API call "GET /accounts" (AISP). It is the same for all other "Bank API Calls".

The following diagram shows all Airlock processing steps for a Bank API Call. The single steps are described in the table below.

Step	Name	Component	Description
1	Check TPP client certificate	Airlock Gateway (WAF)	Terminates TLS and requires a TLS client certificate from the TPP. The Gateway (WAF) checks some aspects on the TLS client certificate (correctness of the signature, trusted issues, etc.) during the TLS handshake.
2	Filtering and access control	Airlock Gateway (WAF)	Filter request as usual (allow rules, deny rules, open API spec enforcement, etc.) and check if request is authorized. Authorization is done for each request (no session): the Gateway (WAF) therefore sends the request to IAM (one-shot call with body).
3	Extract TPP client certificate	IAM	Extracts the TLS client certificate from the request for later inspection. Request without a certificate are rejected.
4	Verify HTTP request signature	IAM	Verifies the HTTP request signature as required in NextGenPSD2. This ensures that the request has not been altered after it left the TPP. The whole request and the signature information can be logged such that the signature can be verified at a later time. The certificate used for signature verification is part of the request. Requests with an invalid signature are rejected.
5	Verify TPP client certificate	IAM	Performs further checks on the TLS client certificate, by looking it up in CRLs and calling OCSP servers. Verifies that the TLS client certificate belongs to the same TPP as the HTTP Signature signing certificate.
6	Find technical client in IAM DB (or add new)	IAM	IAM keeps track of all TPPs' client certificates in its "technical clients" database table. New technical clients are automatically added to the database. An external system (typically the bank) may be informed about new technical clients implementing a custom "interceptor" plugin (e.g. call the bank's REST API).
7	Check if technical client locked in IAM DB	IAM	Checks if the technical client of the TPP is locked (temporarily blocked by a bank's administrator) in IAM's "technical clients" database. If not blocked, IAM signals the "OK" for the request to the Gateway (WAF) and adds a JWT (includes the TPP's ID and roles extracted from the TPP certificate) to the response. Requests on blocked technical clients are rejected.
8	Access Control, forward request	Airlock Gateway (WAF)	Access control again (check, whether the roles provided by IAM are sufficient to let the request pass) and forward request to the bank's API service. The JWT with the TPP ID and roles issued by IAM is attached to the request (as HTTP header). The bank's REST service may use it to process the business call.

User consent (interaction model)

In the following, we illustrate the interaction between the end-user, the TPP and the bank when asking the end-user for a consent.

The consent step is typically initiated by the TPP after the TPP finds out, that user consent is required (e.g. in AISP with consent missing).

Note that this interaction is identical to the traditional usage of Airlock Gateway (WAF) and IAM when protecting web applications:

The protected web application is the bank's "consent application"
Airlock Gateway (WAF) ensures the end-user is authenticated
Airlock IAM authenticates the end-user if necessary.

Step	Name	Component	Description
1	Filtering and access control	Airlock Gateway (WAF)	Filter request as usual (allow rules, deny rules, etc.) and check if session is authorized. In the flow diagram, we assumed that the session is not authorized. If the user has already authenticated before and the session already contains the necessary role, directly continue with step 11.
2	Redirect to IAM to authenticate	Airlock Gateway (WAF)	Since the required role is missing in the Gateway (WAF)'s session, the end-users browser is redirected to IAM's "check-login" end-point.
3	Find target application definition	IAM	Based on the forward location ("Location parameter" = the URL the end-user initially tried to access), IAM finds the corresponding target application definition. It holds information about required roles and identity propagation.
4	Check if required role granted	IAM	Checks whether the end-user has already authenticated and whether the session is already entitled to access the bank's consent application.
5	Interactive Login Process	IAM	If required, IAM authenticates the end-user interactively. This is typically done by responding with "login page" to check username and password but is generally open for any other type of authentication. Note that the 2nd authentication factor (SCA) is typically not part of this authentication process: it will be triggered by the bank's consent application in a later step only if necessary.
6	Check if required role granted	IAM	Check if the required role has been granted after successful authentication. If not, abort.
7	Set Airlock Gateway (WAF) roles	IAM	Inform the Gateway (WAF) about the granted roles, so the Gateway (WAF) can let the original request (1) pass later on.
8	Set JWT for Consent Application	IAM	Store a JWT with the end-user's name, roles (and optionally other information) in the Gateway (WAF)'s session store. The JWT will later be sent to the bank's consent application.
9	Redirect to Consent Application	IAM	Redirect the browser to the bank's consent application.
10	Store Roles and JWT in session	Airlock Gateway (WAF)	Stores the roles and JWT in the session store, i.e. this information is not sent to the end-user's browser.
11	Add JWT to request	Airlock Gateway (WAF)	Add JWT with username and roles to the request for the bank's consent application.