Provide security mechanism to mitigate Session Fixation in cross-device flow with direct_post

Author: Vanderkast

1.1/openid-4-verifiable-presentations-1_1.md

@@ -1851,8 +1851,8 @@ However, the Response Mode `direct_post` is susceptible to such an attack as the
 
 This kind of attack can be detected if the Response Mode `direct_post` is used in conjunction with the redirect URI, which causes the Wallet to redirect the flow to the Verifier's frontend at the device where the transaction was concluded. The Verifier's Response URI MUST include a fresh secret (Response Code) into the redirect URI returned to the Wallet and the Verifier's Response URI MUST require the frontend to pass the respective Response Code when fetching the Authorization Response. That stops session fixation attacks as long as the attacker is unable to get access to the Response Code.
 
-Note that this protection technique is not applicable to cross-device scenarios because the browser used by the Wallet will not have the original session.
-It is also not applicable in same-device scenarios if the Wallet uses a browser different from the one used on the presentation request (e.g. device with multiple installed browsers), because the original session will also not be available there. (#dc_api) provides an alternative Wallet invocation method using web/app platform APIs that avoids many of these issues.
+Note that this protection technique requires a modification to be applicable to cross-device scenarios because the browser used by the Wallet will not have the original session.
+It is also requires a modification to be applicable to same-device scenarios if the Wallet uses a browser different from the one used on the presentation request (e.g. device with multiple installed browsers), because the original session will also not be available there. The Response Code must be trated as a End-User mediated short-lived One-Time Password. The Verifier's frontend that starts the transaction MUST provide an input field for the Response Code. The Verifier's frontend that End-User is redirected to must display the Response Code and instruct the End-User to enter the Response Code only into the same Verifier frontend that initiated the transaction. The End-User enters Response Code into the provided input field so the Verifier's frontend is able to fetch the Authorization Response. (#dc_api) provides an alternative Wallet invocation method using web/app platform APIs that avoids many of these issues.
 
 See (#implementation_considerations_direct_post) for more implementation considerations.