Good catch there. The specification doesn't directly point to the concrete requirements, because of the way that webtransport is architected. The API spec references the overview, which only indirectly describes the functions that specific concrete versions of the protocol implement.
https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3#section-4.8 describes what to do when HTTP/3 is used, which does exactly as Adam describes. That's probably worth some effort to address, because it's easy to reach a bad conclusion. (In other words, Adam's choice of wording here might have been unfortunate, but there's no funny business going on.) On Wed, Sep 16, 2026 at 7:34 AM Jeffrey Yasskin <[email protected]> wrote: > > On Tue, Sep 15, 2026 at 9:45 AM Chromestatus > <[email protected]> wrote: >> >> Contact emails >> [email protected] >> >> Explainer >> https://github.com/w3c/webtransport/blob/main/explainer.md >> >> Specification >> https://www.w3.org/TR/webtransport/#dom-webtransport-exportkeyingmaterial >> >> Summary >> Adds WebTransport.exportKeyingMaterial(), which allows an application to >> derive cryptographic keying material bound to an established WebTransport >> session. The method accepts application provided binary label and context >> values and a requested output length and returns a Promise<Uint8Array>. >> Chromium supports label and context values up to 255 bytes and output >> lengths from 1 through 4096 bytes. For WebTransport over HTTP/3, Chromium >> includes the WebTransport CONNECT stream ID in the TLS exporter context. >> This ensures that separate WebTransport sessions derive different keying >> material even when they share the same underlying HTTP/3 connection. > > > Quick question. My understanding is that, in order for this to work, both > ends of the TLS session need to compute the same keying material. Since the > other end won't be a Chromium browser, I'm worried to see "Chromium includes" > here, rather than a reference to a standard that defines how to include that > stream ID. The spec seems to just say "Let keyingMaterial be a Uint8Array > that is produced by invoking a TLS key exporter, as defined in > [WEB-TRANSPORT-OVERVIEW] Section 4.1, with label, context, and > outputLength.", which doesn't say how to combine the stream ID into the > context. > > Are y'all working on tightening this specification, or have I missed a place > where it actually is already rigorous? > > Thanks, > Jeffrey > > >> >> Blink component >> Blink>Network>WebTransport >> >> Web Feature ID >> webtransport >> >> Motivation >> Applications sometimes need cryptographic keying material bound to an >> authenticated transport session, for example to bind an application >> protocol, authentication exchange, or application-level encryption context >> to a WebTransport session without performing an additional key exchange. TLS >> exporters derive application-specific secret material without exposing the >> TLS traffic keys. WebTransport.exportKeyingMaterial() exposes this >> mechanism through application-provided binary label and context values and >> an explicit output length. Multiple WebTransport sessions can share one >> HTTP/3 connection. Chromium therefore includes the WebTransport CONNECT >> stream ID in the exporter context, ensuring that different sessions derive >> different keying material even when callers use identical application labels >> and contexts. >> >> Initial public proposal >> https://github.com/w3c/webtransport/issues/411 >> >> Goals for experimentation >> None >> >> Requires code in //chrome? >> False >> >> Tracking bug >> https://issues.chromium.org/issues/556304550 >> >> Measurement >> Measure correctness and interoperability through Web Platform Tests, the >> WebTransport IDL harness, wpt.fyi results, and feedback from WebTransport >> application and server implementers. Usage will be measured with a >> WebFeature use counter recorded when WebTransport.exportKeyingMaterial() is >> called. No dedicated UMA metric is currently planned, the use counter is >> sufficient to measure web-exposed API adoption >> >> Availability expectation >> Expected to become available across major browser engines as part of the W3C >> WebTransport specification. Firefox has implemented an earlier two-argument >> version of the method but has not yet been verified as supporting the >> current required three-argument signature. No WebKit implementation of this >> specific method has been verified. >> >> Adoption expectation >> Expected to be used by specialized WebTransport protocols that require >> transport-bound authentication, channel binding, or application key >> derivation. It is not expected to be used by most basic WebTransport >> applications. >> >> Adoption plan >> Adoption is expected to occur through WebTransport documentation, >> interoperable WPT coverage, and use by protocol implementations that require >> transport-bound keying material. No origin trial or broad developer campaign >> is currently planned >> >> Estimated milestones >> >> No milestones specified >> >> >> >> Anticipated spec changes >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may introduce >> web compat/interop risk (e.g., changing to naming or structure of the API in >> a non-backward-compatible way). >> >> No API-shape changes are currently anticipated. Chromium implements the >> current required three-argument method from the WebTransport Candidate >> Recommendation. The protocol-level exporter construction should be rechecked >> against the referenced WebTransport overview specification before stable >> launch. >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/4860330806214656?gate=4833344016744448 >> >> This intent message was generated by Chrome Platform Status. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aa97628.f13237a8.13ec.001a.GAE%40google.com. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3DNUD4JbGQXkje4%2BffTtcpv6Srn8MkxrGA-LJu%3DK-Y6tQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DWPD6uRubQReSh71RpJsCsM_Nd6sUdW-KOAswGZs_f1Sg%40mail.gmail.com.
