From e3d5fe2a5f884ed2034ba4a7c8f65af11b5f4229 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 4 Aug 2023 23:45:17 +0200 Subject: [PATCH] fix: typo --- docs/en/relying-party-solution.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 3e7213db5..95788fe20 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -405,7 +405,7 @@ After getting the User authorization and consent for the presentation of the cre .. note:: **Why the response is encrypted?** - The response sent from the Wallet Instance to the Relying Party is encrypted to prevent a malicious agent from gaining access to the plaintext information transmitted within the relying-party's network. This is only possible if the network environment of the relying-party employs `TLS termination `_. Such technique employs a termination proxy that acts as an intermediary between the client and the webserver and handles all TLS-related operations. In this manner, the proxy deciphers the transmission's content and either forwards it in plaintext or by negotiates an internal TLS session with the actual webserver's intended target. In the first scenario, any malicious actor within the network segment could intercept the transmitted data and obtain sensitive information, such as an unencrypted response, by sniffing the transmitted data. + The response sent from the Wallet Instance to the Relying Party is encrypted to prevent a malicious agent from gaining access to the plaintext information transmitted within the Relying Party's network. This is only possible if the network environment of the Relying Party employs `TLS termination `_. Such technique employs a termination proxy that acts as an intermediary between the client and the webserver and handles all TLS-related operations. In this manner, the proxy deciphers the transmission's content and either forwards it in plaintext or by negotiates an internal TLS session with the actual webserver's intended target. In the first scenario, any malicious actor within the network segment could intercept the transmitted data and obtain sensitive information, such as an unencrypted response, by sniffing the transmitted data. Below a non-normative example of the request: