Intent to Ship: WebTransport keying material export

[Chromestatus]

Contact emails

ri...@chromium.org, moni...@microsoft.com

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

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

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?

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.