waiTransport · Content protection

Two protection lanes, each clear about what it covers.

Premium content and private content need different protection. waiTransport will run two lanes, both waiting on player integration, which is on the WAI roadmap. In the protected-path lane, receipts will cover the envelope and every key decision, never the pixels. In the end-to-end lane, the sink can issue every receipt class once it decrypts.

Roadmap Not yet operating. Each open component below is labelled with where it stands on the WAI status page.

The three labels

In the standard
The open component is in the main branch of the WAI open standard. Its link goes to its row on the dated WAI status page, and its notes are that row's.
Building
The open component is in active development, as the WAI status page lists it.
Roadmap
Planned: a WAI roadmap item, or a waiTransport service. Every waiTransport service is on the roadmap; none is operating yet.

Attested, in WAI, means signed by the party that did the work and measured it: a reader can check the signature, not re-measure the figure. It is not hardware attestation.

01 · The lanes

Two lanes, two different promises.

Protected-path lane

For premium content

  • Roadmap· WAI

    Player integration: runtime fallback, two DRM lanes and a continuity harness.

Content whose licence requires a hardware-protected path will be coded with a standard codec and decoded inside the device's protected path. Decoded frames will stay inside that path and never reach the application, so a WAI receipt will cover the envelope, the manifest and each key-release decision, never the pixels. This lane offers no reconstruction at the sink. WAI has no binding to a protected path today; it records key-release decisions.

The service

  • Roadmap· waiTransport

    A key-release service that signs a record of every release and every refusal.

Builds on

  • In the standard

    Key-release decision records: every release and every refusal is a signed receipt.

    Notes Records decisions; speaks no licence protocol.

  • In the standard

    Session-class manifest: an HLS media playlist generated once per session class.

    Notes The signer declares the viewer count behind any per-viewer figure.

  • In the standard

    Relays that forward envelopes and receipts byte for byte.

    Notes A relay attests in a separate, parallel receipt.

End-to-end lane

For private and real-time content

  • Roadmap· WAI

    Player integration: runtime fallback, two DRM lanes and a continuity harness.

Payloads will be encrypted with MLS group keys and SFrame object encryption. The sink decrypts, then dispatches, so it can dispatch every capability, including reconstruction at the sink. After decryption the sink can issue every receipt class; relays attest the encrypted bytes only. This lane does not provide the hardware robustness some premium content licences require.

The service

  • Roadmap· waiTransport

    Managed group keys for the end-to-end lane.

Builds on

  • In the standard

    Encrypted payloads and private channels (MLS and SFrame).

    Notes Specification text in the open-standards repository. Its implementation is a companion implementation outside it, under its own licence, and the demonstration runs on it. The MLS binding follows an individual Internet-Draft that has expired.

  • In the standard

    The signed session claim.

    Notes Timings, missed deadlines and switches remain the signer's statements, as do the facts of an encrypted envelope that only its payload shows. A sink that received a multi-rendition envelope only as byte ranges cannot yet state its classical length.

02 · Limits

What this page does not claim.

  • Neither lane is operating. Neither claims a robustness level or a certification.
  • In the protected-path lane, receipts will never describe pixels the application cannot see.
  • In the end-to-end lane, a relay's receipt covers the encrypted bytes it carried, never the content.
03 · Read next

The text behind this page.