> As you move forward with the PoC, consider: even if you decide not to > become protocol-layer experts, you'll still need to become familiar > with application-layer security in HTTP.
Good point. Application layer security is indeed a concern.
h2 has provisions for security by design, and a significant amount of research going into this on a large scale. Adopting h2 instead of inventing our own v4 gets us all this research for free.
HTTP2, please, not "h2".
It looks HTTP2 does use the term "h2" to mean "http2 over TLS", to differentiate it from "h2c" which is HTTP2-over-cleartext.
IMO, you'd have to support both. Mandating TLS is going to be a non-starter for sites that use loopback connections or virtual switches on VMs, VLAN isolation, or other features to render traffic largely unsniffable. They won't want to pay the price for crypto on all traffic. So this needs to be "HTTP2 support" not "HTTP2/TLS (h2) support" anyway.
Re Pg and security: By and large we don't invent our own security protocols. We've adopted standard mechanisms like GSSAPI and SCRAM, and vendor ones like SSPI. Some of the details of how they're implemented in the protocol are of course protocol specific (and thus, opportunities for bugs/design mistakes), of course.
But you will get _nowhere_ in making this a new default protocol if you just try to treat those as outdated and uninteresting.
In fact, part of extensibility considerations should be extensible authentication.
Authentication and authorization (which any new protocol really should separate) are crucial features, and there's no one-size-fits-all answer.
If you just assume, say, that everything happens over TLS with password auth or x.509 client certs, you'll create a giant mess for all the sites that use Kerberos or SSPI.