The following diagram illustrates 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 diagram is based on the assumption that the TPP has a valid AT* for the call. The AT* is obtained using standard IAM OAuth 2.0 features:
- For PISP calls, the TPP gets the AT* using the Client Creds Flow.
- For AISP calls (and similar calls like CBPII) the TPP gets an AT* as follows:
- Initially, it starts an Authz Code Flow involving User-Consent () and gets an AT* and a RT*
- If the TPP holds a valid RT*, it may get a new AT* by calling IAM's OAuth 2.0 Token Endpoint.
The following diagram shows all Airlock processing steps for a Bank API Call. It assumes that the TPP holds a valid AT*. The single steps are described in the table below.
Step | Name | Component | Description |
|---|---|---|---|
- | Get valid AT*(not in diagram) | TPP, PSU, IAM | The TPP already has or obtains a valid AT* using standard OAuth 2.0 features as described above. |
1 | Check TPP client certificate | Airlock Gateway (WAF) | Terminates TLS and requires a TLS client certificate from the TPP. The Airlock 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 Airlock Gateway (WAF) therefore sends the request to IAM (one-shot call with body). |
3 | Extract TPP client certificate and AT* | IAM | Extracts the TLS client certificate and the AT* 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 STET PSD2. 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 and AT* | 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. Checks if the AT* is valid and if it was issued for the TPP identified by the TLS client certificate. |
6 | 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. |