User-consent
12.6.3.1.3. 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 within an Authz Code Flow.

The consent step is initiated by the TPP after the TPP finds out, that a user consent is required (e.g. in AISP but no valid RT* is available).

Note that this interaction is identical to the standard Authz Code Flow with the TPP being the OAuth Client and IAM being the OAuth Authorization Server (AS).

When asking for the user consent, IAM hands over control to the bank's consent application, because the consent step involves banking specific information (see also 13.3.1.3.1. Remote consent applications with OAuth).

110497743.png
Step
Name
Component
Description
1
Process Authz Code Request
IAM
IAM's AS* (OAuth 2 Authorization Server) processes the request from the TPP (forwarded to IAM via the PSU's browser). The AS checks the requested scopes, requested token type and more.
2
Check if PSU is authenticated
IAM
Check if the PSU (end-user) is authenticated and has enough roles to proceed. If not start the interactive authentication process.
3
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.
4
Start Remote Consent
IAM
After successful authentication, IAM starts the "remote consent" protocol: it redirects the browser to the bank's consent application and prepares a JWT bearing the required information to do so.
The bank's consent application is protected by a Airlock Gateway (WAF) role.
5
Store Role
Airlock Gateway (WAF)
The Airlock Gateway (WAF) stores the role received by IAM and required to access the bank's consent application in the session store. It is used for access control in the next request.
6
Access Control and Filtering
Airlock Gateway (WAF)
Filter request to bank's consent application and do access control (ensure role).
-
Remote Consent
Bank's Consent Application
The bank's consent application can now interact with the PSU (end-user) in order to get a consent. It confirms (or declines) the consent back to IAM by sending back another JWT token. See also 13.3.1.3.1. Remote consent applications with OAuth.
7
Verify Consent JWT
IAM
Verify the consent JWT received from the bank's consent application. If no consent has been given, the process is aborted at this point.
8
Generate Authz Code and store in DB
IAM
Generate Authz Code and store it in the OAuth 2 session database.
9
Issue Authz Code
IAM
Send Authz Code back to TPP (using a HTTP redirect via the PSU's browser).
10
Verify Client Certificate and Client ID
IAM
After the TPP received the Authz Code, it will send it to IAM in order to get an AT* and RT*. IAM verifies the TPP's client certificate, its Client ID and the Authz Code.
11
Issue AT* and RT*
IAM
IAM issues an AT* and RT* and sends it back to the TPP.