LGTM3 On Tue, Oct 27, 2026 at 11:37 PM Mike Taylor <[email protected]> wrote:
> LGTM2 > On 10/27/26 7:00 p.m., Alex Russell wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a5388d9-892a-48a3-b39a-ebc57635aa98n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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/96b5ba8b-fc57-4a51-96d2-1a75b4d1de5d%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/96b5ba8b-fc57-4a51-96d2-1a75b4d1de5d%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw9j0MTrEkwaXS0OAOn49i7uoD5MRUniEN%2B1VH58JbWpTQ%40mail.gmail.com.
