EZDRM C2PA Live Signer

This is the most interesting thing anyone has put inside a MoQ relay so far, and it deserves attention beyond the DRM audience.

C2PA is the provenance standard — a cryptographic seal embedded in content that lets a viewer verify who made it, who distributed it, and whether it has been altered. It was designed for files. EZDRM’s Live Signer signs every segment of a live stream in real time, from within a MoQ relay, so provenance becomes a property of the delivery path rather than something applied before or after it.

How it was built

Developed by EZDRM with Qualabs as implementation partner, with Cloudflare joining to supply relay infrastructure and Ateme handling packaging. The integration required extending three open-source projects:

• moq-relay — adapted to sign content in real time as each segment arrives
• c2pa-rs — extended to handle live CMAF streams rather than static files
• c2pa-js — tuned so player-side verification happens seamlessly during playback

The result is a signing proxy that ingests fragments, processes each live fMP4 segment, hashes and chains them with anchor-point resets, signs using the C2PA toolchain, and embeds both signature and hash into the segment’s uuid box. Playback-side validation then detects tampering, rebroadcast, or AI-generated manipulation.

Notably, the team reports building this from scratch in about three weeks with no existing reference integration, because C2PA live signing and MoQ had never been combined with DRM in one workflow before.

Why it matters for MoQT

Signing at the relay is an architectural choice with consequences worth thinking through, and they are worth stating plainly because this is the first place the question has become concrete rather than theoretical.

The relay stops being a forwarder. To sign each segment it must read the payload, hash it, and rewrite the object to embed the signature in the uuid box. That is a departure from the caching-and-fan-out model described in How MoQT Relays Work, where a relay routes objects it never needs to interpret.

It runs against the direction of the working group’s security work. draft-ietf-moq-secure-objects specifies end-to-end object encryption precisely so that relays cannot read object contents. It was proposed for working group last call at IETF 126 and is, per the chairs, likely to be the first MoQ draft to reach that milestone — so this is settled direction, not speculation. An architecture that requires payload access at the relay and an architecture that denies it cannot both be applied to the same objects.

The same instinct shows up elsewhere in the WG record. In the authorization design team discussions, Ted Hardie’s standing constraint is that relays required to maintain subscriber databases are a privacy liability. The consistent thread is that the working group is trying to shrink what a relay must be trusted with, not grow it.

None of which makes this integration wrong. There are readings where the two reconcile: sign before encrypting, so provenance is established at the origin and the relay only forwards; or treat the signing relay as inside the content owner’s trust boundary rather than as shared infrastructure, which is a reasonable model for a first-party origin shield and an unreasonable one for a public CDN edge. The demo predates Secure Objects reaching last call, and it was built in three weeks to prove a pipeline could exist at all.

The open question — and it is a real one for anyone planning a deployment — is which of those readings the ecosystem lands on. If provenance signing needs relay-side payload access at CDN scale, and Secure Objects needs relay-side opacity, then somebody has to give, and it is better to know that before building on either.

Ecosystem position

Demonstrated at NAB 2026 across the EZDRM, Ateme, and Cloudflare booths. EZDRM is a long-standing DRM-as-a-service vendor and an active contributor to the C2PA standards work for live video.