From 3e466d416b1966358ac00230c9bfb08a831eef93 Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Thu, 12 Mar 2026 18:37:01 +0400 Subject: [PATCH 1/2] Provide security mechanism to mitigate Session Fixation in cross-device flow with direct_post --- 1.1/openid-4-verifiable-presentations-1_1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 32e4b046..44be96d9 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/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. From 5505b19b7accc3aa4ae9d06fae16eac07793e36e Mon Sep 17 00:00:00 2001 From: Valentine Mazurov Date: Thu, 12 Mar 2026 18:39:00 +0400 Subject: [PATCH 2/2] Minor grammar fix --- 1.1/openid-4-verifiable-presentations-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 44be96d9..0b58ddc6 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1852,7 +1852,7 @@ 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 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. +It 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.