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
<https://github.com/w3c/webtransport/blob/main/explainer.md>
*Specification*
https://www.w3.org/TR/webtransport/#dom-webtransport-exportkeyingmaterial
<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
<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
<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
<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
<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
<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/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
<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
<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
<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
<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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a5388d9-892a-48a3-b39a-ebc57635aa98n%40chromium.org?utm_medium=email&utm_source=footer>.
