serverCertificateHashes

[martenrichter]

What problem are you trying to solve?

Authenticate with a vm that is spun up automatically and does not have a certificate signed by valid certificate chain.

What solutions exist today?

For webtransport, the option "serverCertificateHashes" exists, which will be soon be supported by at least two major browser engines.
For now, in environments with only TCP/IP support the alternative transports over http/2 are not implemented yet and one major browser has no webtransport support at all. So if websockets are used as fallback, they need a different certificate chain than the webtransport, if serverCertificateHashes would be used.

How would you solve it?

Support for serverCertificateHashes, may be use as alternative second argument to the WebSocket contructor an options object:

new WebSocket(url, {protocols: [...], serverCertificateHashes: [...]}

this would allow to run the WebTransport fallback in the same way as the WebTransport connection.

Anything else?

Depending on the implementation side effects to the fetch api need to be considered.

[ricea]

I'm not sure it would be faster to specify and implement this for WebSockets than to add HTTP/2 transport and missing browser support to WebTransport. In both cases you're blocked on implementations catching up. WebTransport has more momentum at the moment, so I would expect it to cross the finish line first.

[martenrichter]

Well, this is true... the implementations are the blocking point.

[martenrichter]

I think again about this point. I see little progress regarding http2 implementation in web transport. (Correct me if I am wrong)
Implementing a server certificate hashes mechanism is relatively easy (I contributed to the gecko webtransport patch as this feature is really essential), even if one would do it for the major browser engines.
So the question is, would there be support?
This way, my web transport over WebSocket polyfill can fill the application gap until an http2 implementation arrives.