Hi @wilaw,

The WebTransport proposal is moving in a positive direction and demonstrates maturity, with multi-stakeholder support. This is a promising foundation for further development.

However, there are some concerns that need to be addressed:

• Certificate Hash as Authentication: It is unclear whether the certificate hash digest is used for authentication. Based on the context, it seems the digest serves as proof of certificate ownership for an already established channel, which justifies its use. The text explicitly states,

  certificate verification errors are considered critical (fatal) and cannot be bypassed.

  Our concerns are:

  1. Fallback Mechanism: Can you please clarify which of these scenarios happen in case of certificate error?
     • A new TLS handshake (or equivalent) is re-initiated.
     • The same digest is resent until verification completes at the server-side through the same established TLS session.
  2. Bi-Directional Authentication: Given the bi-directional nature of communication, authentication could benefit from a bi-directional approach. While the state-persistence approach (relying on TLS session tickets) is fair, certificate verification errors could make client authentication (and state persistence) non-deterministic. Can you please provide more specifics on this?

• Privacy Concerns with WebTransportConnectionStats: The discussions on side-channel passive fingerprinting based on WebTransportConnectionStats are a reasonable starting point. However, the TAG encourages you to explore more privacy-preserving approaches for presenting fine-grained stats. For example, adopting a tier-based nomination of quantities, similar to the "performance Tiers" in the CPU Performance API, could be a viable solution.

Thanks @toreini for the positive general assessment! But I suspect some misunderstandings in the specific feedback:

It is unclear whether the certificate hash digest is used for authentication ... it seems the digest serves as proof of certificate ownership for an already established channel ... Fallback ... resent until verification completes at the server-side through the same established TLS session.

This sounds like a separate authentication step layered on top of a connection that already exists, with some retry behavior when it fails...

But serverCertificateHashes is not that. It's an option to the TLS connection being created in the first place:

• "If webTransportHashes is not empty, instead of using the default certificate verification algorithm, consider the server certificate valid if it meets the custom certificate requirements and if verifying the certificate hash against webTransportHashes returns true. If either condition is not met, then return failure."

The server doesn't verify the hash — the client does. In TLS authentication, the client checks the server's certificate. The hash just replaces the trust-anchor on the client side.

Its value (and risks) have been discussed at some length already in https://github.com/w3c/webtransport/issues/623. But TL;DR:

The only substantive difference between this and a certificate is that a certificate can be revoked. But, because hashes are downstream of another certificate that can be revoked (the one issued to the site that is making the WebTransport session), the change in risk profile seems tolerable. All of the other things that people tend to think are problems with hashes in this context don't apply, because the client is still entirely dependent on the site that initiates the session. The site is equally capable of spinning up a new DNS name for this, which could be hosted just about anywhere. The advantage of the hash is real: the site doesn't need to get a certificate, which adds real latency to the setup of on-demand services.

This has passed two previous TAG reviews https://github.com/w3ctag/design-reviews/issues/669 https://github.com/w3ctag/design-reviews/issues/389, even before we added CSP support. https://github.com/w3c/webappsec-csp/pull/791

Given the bi-directional nature of communication, authentication could benefit from a bi-directional approach. While the state-persistence approach (relying on TLS session tickets) is fair, certificate verification errors could make client authentication (and state persistence) non-deterministic

This is server authentication, not client authentication. HTTP is also bidirectional, but we have a well-established one-sided authentication model at the TLS layer.  This relies on exactly the same arrangement.

The discussions on side-channel passive fingerprinting based on WebTransportConnectionStats are a reasonable starting point. However, the TAG encourages you to explore more privacy-preserving approaches for presenting fine-grained stats. For example, adopting a tier-based nomination of quantities...

This is being addressed with https://github.com/w3c/webtransport/pull/764 and https://github.com/w3c/webtransport/pull/766. PTAL.

The spec could perhaps be clearer about the fact that these stats are things that the server (which is explicitly chosen by the site and is directly aware of the identity of the site when accepting a connection) can measure.  The stats API only makes it easier for sites to gather the information. We can add text clarifying that the server already has this info.

Tier-based quantization wouldn't change that, because it'd quantize the client-side copy while the server keeps the full-resolution original.

Please let us know if this clarifies, or if you have other questions.