Why I'm posting this
We've been building OTNet's BuyDRM integration end to end and I wanted to share the current shape with the BuyDRM team and anyone who's done this before. The video above walks through the producer side (encoding a master in the desktop app, generating keys, packaging DASH and HLS outputs with Shaka Packager) and the viewer side (the OTNet player resolving a session token, fetching a license, and playing back protected content). If anything in the flow looks off, or there's a better pattern we should be using, I'd genuinely like to hear it.
The flow, in short
A producer drops a master file into the OTNet desktop app. The app encodes the renditions, generates content keys, registers those keys with BuyDRM KeyOS under the publisher's organization, packages the output as DASH and HLS, and uploads to cloud storage. The content is then registered on the OTNet control plane and becomes available to publish.
On playback, the OTNet player asks the website for a short lived JWT proving the viewer is allowed to watch that specific piece of content. The player then sends its license requests through an OTNet proxy endpoint rather than hitting BuyDRM directly. The proxy unwraps the publisher's BuyDRM credentials from the database (AES 256 GCM, stored per organization), forwards the request to KeyOS with the correct authorization, and pipes the license response back to the player.
What's working well
The session DRM proxy means the viewer never sees the publisher's KeyOS credentials, and the publisher never has to expose them in a player config or a client side fetch. Switching providers (BuyDRM, EZDRM, others) becomes a settings change rather than a code change. Widevine and PlayReady route through the same proxy. FairPlay also routes through the proxy and uses the certificate URL the publisher has configured.
Shaka Packager produces both DASH and HLS outputs from the same encode. The player picks the right manifest per platform (DASH for Widevine and PlayReady, HLS for FairPlay on Safari and iOS).
Where I'd love advice
First, key rotation. We rotate content keys on a per asset basis today. Is there a recommended cadence or pattern for rotating at the publisher or organization level on KeyOS without breaking existing entitlements?
Second, per viewer and per device binding. We're planning to add device binding for premium tiers. I'd like to understand the recommended way to express that in the KeyOS policy and how it interacts with offline playback if we add downloads later.
Third, observability. We log every license issuance through the proxy with a request id, content id, viewer id, and KeyOS response status. Is there anything on the BuyDRM side we should be capturing or correlating that would help us debug a failed playback faster?
Fourth, anything that's an obvious anti pattern. If the proxy approach itself is a bad shape (latency, retries, failure modes), I'd rather hear it now than after we've shipped it to more publishers.