The following diagram illustrates the interaction between the TPP and IAM to register the TPP's OAuth 2.0 Client with the bank.
Step | Name | Component | Description |
|---|---|---|---|
1 | Check TPP client certificate | Airlock Gateway | Terminates TLS and requires a TLS client certificate from the TPP. The Airlock Gateway checks some aspects on the TLS client certificate (correctness of the signature, trusted issues, etc.) during the TLS handshake. |
2 | Filtering | Airlock Gateway | Filter request as usual (allow rules, deny rules, open API spec enforcement, etc.) |
3 | Extract TPP client certificate | IAM | Extracts the TLS client certificate from the request for later introspection. Request without a certificate are rejected. |
4 | Process registration request | IAM | Process the OAuth 2.0 Dynamic Client Registration request (e.g. check if required client authentication method is allowed). |
5 | Generate Client ID | IAM | Generate an Client ID for the newly registered Client. No client secret is generated since TPP's Clients must authenticate using client certificates. |
6 | Store new OAuth 2 Client in IAM DB | IAM | The newly registered Client is stored in the IAM database. An external system (typically the bank) may be informed about new Clients implementing a custom "interceptor" plugin (e.g. call the bank's REST API). |