- From: Ehsan Toreini <notifications@github.com>
- Date: Thu, 11 Jun 2026 02:40:43 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1212/4679222226@github.com>
toreini left a comment (w3ctag/design-reviews#1212)
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](https://wicg.github.io/cpu-performance/#tiers), could be a viable solution.
--
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1212#issuecomment-4679222226
You are receiving this because you are subscribed to this thread.
Message ID: <w3ctag/design-reviews/issues/1212/4679222226@github.com>
Received on Thursday, 11 June 2026 09:40:47 UTC