IETF MOQ WG: Capability preflight for CMSF: verifying client capabilities before track authorization

Message Snapshot

• List: moq@ietf.org
• Thread subject: Capability preflight for CMSF: verifying client capabilities before track authorization
• Message subject: [Moq] Capability preflight for CMSF: verifying client capabilities before track authorization
• Author: David C. Eisenbacher
• Published: 2026-10-30T14:19:00.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

David C. Eisenbacher posted to the MOQ working group mailing list on October 30, 2026. Hi all, I'd like to propose an optional capability preflight for CMSF and get the working group's view before taking it further. The…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Hi all, I'd like to propose an optional capability preflight for CMSF and get the working group's view before taking it further. The PR is:

Plain-Text Body

Hi all,

I'd like to propose an optional capability preflight for CMSF and get the working group's view before taking it further. The PR is:

https://github.com/moq-wg/cmsf/pull/29

It started as an MSF proposal (https://github.com/moq-wg/msf/pull/214, now closed). Following Will's review, it now lives in CMSF, where it has a direct use.

The problem

In an MSF/CMSF session today the order is: catalog, token, SUBSCRIBE, media, license. The first check of the client itself, such as its DRM security level, happens at license acquisition. By then the client has learned every track name, been authorized by the relay, and received the encrypted media. This has a few consequences:

• The license server is the only gate. One key-policy mistake (a key shared across renditions, or between audio and video) exposes premium content to any token holder.
• Encrypted high-value tracks go to clients that could never be licensed for them, which costs egress and makes any later key compromise worth more.
• Client-reported capabilities, such as EME robustness, can be faked by page script.
• Track authorization and license policy are decided separately, so ABR can pick a rendition the license server will then refuse.

The proposal

Before authorization is issued for tracks marked preflightRequired, the publisher sends the subscriber a preflight request (nonce, expiry, probes) on an event timeline track. The subscriber runs the probes and returns the results over HTTPS or a publish track. The publisher verifies them and returns a decision listing authorized and denied tracks, plus a token scoped to the authorized tracks. The relay enforces that scope as it does any other token. A fallback catalog covers clients that don't support preflight.

The mechanism is independent of DRM. What gets checked is defined by probe types in a registry. The first is a content protection probe. Its evidence is a license request signed by the client's CDM for a canary key, with the preflight nonce embedded in integrity-protected init data, so spoofed or replayed claims are caught before the client gets any media. The license server still enforces independently: preflight adds a second gate, not a replacement. The draft also defines decode, display and clock probes.

Questions for the group

1. Is the problem worth solving in CMSF, and is preflight the right shape for it?
2. Is a canary key with the nonce in integrity-protected init data an acceptable DRM-neutral way to bind evidence, or should each DRM system's binding be specified separately?
3. Should the probe registry sit in the MSF parameters registry group, so the mechanism can move into MSF later if a non-DRM use appears (for example platform attestation for clear content)?
4. Is the key-separation guidance (per security level, audio vs video) in scope for CMSF, or better left to DASH-IF ECCP?

I'd also like to request time at IETF 127 to walk through the workflow. Comments here or on the PR are ver…