LGTM1 On Wednesday, October 21, 2026 at 12:09:28 PM UTC-7 Chromestatus wrote:
> *Contact emails* > [email protected], [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. > > *Blink component* > Blink>Network>WebTransport > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> > > *Web Feature ID* > webtransport <https://webstatus.dev/features/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 > > *TAG review* > This is an incremental method within the existing WebTransport > specification. WebTransport has an umbrella TAG review, and a separate > feature-level review is not currently planned. > > *TAG review status* > Not applicable > > *Goals for experimentation* > None > > *Risks* > > > *Interoperability and Compatibility* > Interoperability risk: Medium. The current WebTransport specification and > upstream WPT define the required three-argument > exportKeyingMaterial(label, context, outputLength) method. Chromium and > WebKit implement this shape. Firefox currently exposes the earlier > two-argument form without outputLength , so API-shape interoperability is > not yet complete. Implementations and servers must also use the same fixed > exporter label and exporter-context construction, including the > WebTransport session ID, application label, application context, and > requested output length. A mismatch produces different bytes without an > explicit protocol error. Compatibility risk: Low. The method is additive > and does not change existing WebTransport construction, streams, datagrams, > or connection behavior. Applications can use feature detection with > "exportKeyingMaterial" in WebTransport.prototype. > > *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=2079306) > Firefox > is updating its implementation to the current three-argument API. > > *WebKit*: In development (https://github.com/WebKit/WebKit/pull/69982) WebKit > has landed an implementation of the current three-argument > WebTransport.exportKeyingMaterial(label, context, outputLength) API. > > *Web developers*: Positive (https://github.com/w3c/webtransport/issues/411) > The > proposal received 10 👍 reactions and requests from developers, including > libp2p, for TLS-session binding and channel-binding use cases. > > *Other signals*: > > *Ergonomics* > Ergonomics risk is moderate because this is a low-level cryptographic > primitive. Binary BufferSource label and context values avoid > string-encoding ambiguity, while the explicit output length avoids an > implicit key-size choice. Calls made while the WebTransport session is > connecting are queued until the connection is established. Calls after > closure or failure reject with InvalidStateError . Label or context values > over 255 bytes and zero or unsupported output lengths reject with > RangeError . Documentation should recommend protocol-specific > domain-separation values and secure handling of the resulting bytes. > > *Activation* > Activation risk is moderate but bounded. The API is additive and has no > effect unless a site explicitly invokes it. It introduces no new network > messages or additional protocol negotiation. The main activation risk is a > mismatch between client and server implementations in the exporter > construction, including the fixed exporter label, WebTransport session ID > serialization, application label or context, and output length. Such a > mismatch causes the endpoints to derive different bytes without an explicit > error. Chromium mitigates this risk through validation in Blink and across > the renderer/network-service boundary, fixed input limits, session-specific > domain separation, lifecycle checks, unit and Web Platform Tests, and the > WebTransportExportKeyingMaterial runtime/Finch feature gate. > > *Security* > This API exposes secret-derived material to script and therefore requires > careful domain separation and lifecycle handling. It does not expose TLS > traffic keys or allow callers to decrypt WebTransport traffic. Chromium > uses the fixed TLS exporter label "EXPORTER-WebTransport" and constructs > an exporter context containing the WebTransport CONNECT stream ID, > application label, and application context. Including the CONNECT stream ID > prevents different WebTransport sessions sharing one HTTP/3 connection from > deriving identical keying material when given the same application inputs. > Chromium limits label and context values to 255 bytes and output to 4096 > bytes, validates requests in both Blink and the network service, verifies > the returned output length, and rejects calls after the session has closed > or failed. Applications remain responsible for treating the result as > secret keying material and using protocol-specific label and context values > Security questionnaire: > https://github.com/w3c/webtransport/blob/main/security-questionnaire.md > > *WebView application risks* > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > Low. This is an additive API implemented in shared Blink and > network-service code. The CL updates the Android WebView Web-exposed > interface expectation and requires no WebView-specific integration. Stable > WebView exposure should follow the existing availability and launch process > for WebTransport in WebView. > > > *Debuggability* > Developers can inspect the label, context, output length, returned > Uint8Array, and any rejected exception through JavaScript breakpoints or > the Console. CDP exposes WebTransport creation, connection-establishment, > and closure events. NetLog provides additional WebTransport version, QUIC > lifecycle, and stream diagnostics. Neither CDP nor NetLog records exporter > invocations, exported bytes, or compares the client-derived value with the > server-derived value. A client/server derivation mismatch therefore > requires server cooperation, preferably through a key-confirmation > challenge or MAC rather than logging raw keying material. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes > All Blink platforms on which WebTransport over HTTP/3 is supported. The > Web-exposed implementation is cross-platform Blink code, while key > derivation uses Chromium’s existing HTTP/3/QUIC TLS exporter path. > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > > https://wpt.fyi/results/webtransport/export-keying-material.https.any.html?label=experimental&label=master&aligned, > > > https://wpt.fyi/results/webtransport/idlharness.https.sub.any.html?label=experimental&label=master&aligned > > > *Flag name on about://flags* > chrome://flags/#enable-experimental-web-platform-features > > *Finch feature name* > WebTransportExportKeyingMaterial > > *Rollout plan* > Will ship enabled for all users > > *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. WebKit has landed the current > three-argument API in WebKit main, although stable Safari availability has > not yet been verified. Firefox currently implements the earlier > two-argument form without the required outputLength argument. > > *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* > Shipping on desktop 158 > Shipping on Android 158 > Shipping on WebView 158 > > *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 and matches the > WebTransport-over-HTTP/3 exporter construction, including the fixed > exporter label and session-specific context encoding. > https://github.com/w3c/webtransport/issues/791 tracks making the > specification’s reference to the protocol-level exporter construction more > explicit. This is currently an editorial clarity issue rather than a known > behavior change. > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/4860330806214656?gate=6662931365363712 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aa97628.f13237a8.13ec.001a.GAE%40google.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.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/3a5388d9-892a-48a3-b39a-ebc57635aa98n%40chromium.org.
