@YKtI98D-1mmo
"Our security group immediately disqualified SAP because HTTP 1.1 means that HTTP traffic containing payments and tax info will not be encrypted."
For secured communication and encryption, the standard implementation is using HTTPS. This is what is being used for all online payment transactions, email communication etc. Your security group should know that, right?
See here: https://en.wikipedia.org/wiki/HTTPS
about HTTP 2, based on https://en.wikipedia.org/wiki/HTTP/2
"According to W3Techs, as of April 2019, 36.2% of the top 10 million websites supported HTTP/2"
.....
"Encryption
HTTP/2 is defined both for HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS using ALPN extension where TLS 1.2 or newer is required).
Although the standard itself does not require usage of encryption, all major client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.
......
Encryption
Initially, some members[who?] of the Working Group tried to introduce an encryption requirement in the protocol. This faced criticism.
Critics stated that encryption has non-negligible computing costs and that many HTTP applications have actually no need for encryption and their providers have no desire to spend additional resources on it. Encryption proponents have stated that this encryption overhead is negligible in practice.[36] Poul-Henning Kamp has criticised IETF for following a particular political agenda with HTTP/2.[35][37][38] The criticism of the agenda of mandatory encryption within the existing certificate framework is not new, nor is it unique to members of the open-source community – a Cisco employee stated in 2013 that the present certificate model is not compatible with small devices like routers, because the present model requires not only annual enrollment and remission of non-trivial fees for each certificate, but must be continually repeated on an annual basis.[39] Working Group finally did not reach consensus over the mandatory encryption,[32] although most client implementations require it, which makes encryption a de facto requirement.
The HTTP/2 protocol also faced criticism for not supporting opportunistic encryption, a measure against passive monitoring similar to the STARTTLS mechanism that has long been available in other Internet protocols like SMTP. Critics have stated that the HTTP/2 proposal goes in violation of IETF's own RFC7258 "Pervasive Monitoring Is an Attack", which also has a status of Best Current Practice 188.[40] RFC7258/BCP188 mandates that passive monitoring be considered as an attack, and protocols designed by IETF should take steps to protect against passive monitoring (for example, through the use of opportunistic encryption). A number of specifications for opportunistic encryption of HTTP/2 have been provided,[41][42][43] of which draft-nottingham-http2-encryption was adopted as an official work item of the working group, leading to the publication of RFC 8164 in May 2017."