AS Mix-Up Attack on IAE

@PedramHD and I briefly looked into the PR #589 from a security perspective and found a possible AS Mix-Up attack if the Interactive Authorization EP is used.
We assume the following setting: There is an ecosystem with multiple AS that support the IAE, and some of them can be malicious or have been hacked. In this ecosystem, an honest wallet w uses an attacker AS. In the metadata, the attacker AS specifies the Interactive Authorization EP of an honest AS.

The attack consists of the following steps:
(1) w wants to use the attacker AS, sends an Interactive Authorization Request to the endpoint of the honest AS
(2) The honest AS responds with type = openid4vp_presentation and an auth_session
(3) In the Follow Up Request, w sends a presentation and the auth_session to the Interactive Authorization EP of the honest AS
(4) The honest AS responds with a code
(5) w sends the token request to the attacker AS, i.e., the attacker receives the code together with the matching PKCE verifier
(6) The attacker uses the code and the PKCE verifier on the token EP of the honest AS and receives an access token

This would also be possible through PR #589 in the redirect_to_web case, i.e., the attacker would specify the Interactive Authorization EP and Authorization EP of the honest AS in its metadata. The PR states: “If the Authorization process is not complete when this redirect occurs, the Authorization Server returns a response with the auth_session parameter.” The way we interpret this is that this response is not a normal authorization response, so recommendations regarding iss response parameters from the Security BCP would not apply.