Interaction models STET 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.

Used OAuth abbreviations:

We use the following OAuth 2.0-related abbreviations to keep the texts more readable.

Stands for
OAuth 2.0 Authorization Server (Airlock IAM)
OAuth 2.0 Client (the TPP)
OAuth 2.0 Access Token
OAuth 2.0 Refresh Token
Authz Code Flow
OAuth 2.0 Authorization Code Flow
Authz Code
OAuth 2.0 Authorization Code
Client Creds Flow
OAuth 2.0 Client Credentials Flow
Client ID
OAuth 2.0 Client Identifier

OAuth 2 Usage in STET

STET makes use of the following OAuth 2.0 concepts:

  • Dynamic Client Registration: for Client registration 
  • Client Creds Flow: to authorize the Client for payment-related calls (PISP)
  • Authz Code Flow: to authorize the Client for account-related (AISP) and similar (e.g. CBPII) calls. This may involve the end-user for giving consent.
  • OAuth 2.0 client authentication: the Client's OAuth 2.0 client(s) are authenticated using client certificates

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

Airlock Concepts
STET uses OAuth 2.0 for TPP authentication and access delegation. Therefore, each TPP's OAuth client(s) must register using IAM's OAuth 2.0 client registration API in order to be able to use the bank's APIs.
OAuth 2.0 Dynamic Client Registration
All REST API calls from the TPP to the bank's REST services.
Examples: Requests on REST resources /accounts, /payments, /consents, etc.
One-Shot Authentication Flow
(HTTP request authentication)
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.
  • OAuth 2.0 Authorization Code Flow
  • Remote Consent