The two sessions approach
the purpose of the state parameter shall be solely to protect a corresponding session against CSRF
Timeout of PSU2TPP session: This can be addressed either by your approach with two different sessions (which is already common in the e-commerce space)
I prefer the two sessions approach (like you mention above common in the e-commerce space):
A psu2tpp session (login_session) that is active while interaction between psu agent and tpp server is active. Corresponding session cookie shall be deleted prior to redirecting the user to the AS.
A redirect_session that is active when a redirect is going on. This shall also be set to expected time the psu need to authenticate with the AS and authorize the transaction.
or by storing timestamps in the PSU2TPP session and requiring a reauthentication of the user when a certain age of the last login is reached (no need to rely on the built-in timeout of the session or cookie).
It is better to always delete the psu2tpp session prior to redirecting the user to another domain. Keeping this session will require reusing the corresponding state parameter in the redirect process.
Ensuring that the browser used to interact with the TPP and the one interacting with the ASPSP are the same: Except for token binding, I’ve not seen a really good solution for this problem yet.
Although this is important, I rather define PSU identity equivalence like this: the PSU interacting with the ASPSP is the same as the PSU interacting with the TPP. Depending on the user device and redirection type, both user agents (PSU ↔︎ ASPSP) and (PSU ↔︎ TPP) might be the same browser instance or not (e.g. browser and native app).
If the browser used for (PSU ↔︎ TPP) stores a redirect_session prior to redirecting the user to the ASPSP, the url redirecting the PSU from the ASPSP back to the TPP can bring a state parameter that is used to retrieve and unlock the redirect session.
If the TPP application is designed to hold the code_verifier in the redirect_session, then you have a sufficient level of assurance that you are dealing with the same PSU on both ASPSP and TPP interface.
