cta-wave / technical-working-group

7 stars 0 forks source link

DRM use cases #5

Open wilaw opened 6 years ago

wilaw commented 6 years ago

[Kilroy Hughes] - In the TWG call today, I took the action item to report and coordinate discussion with multiDRM companies, and track development of WAVE DRM test requirements, which will likely be built initially on services these DRM providers currently offer.

Questions like those below will likely require dialog with the multiDRM provider(s) so we can ask just those questions: How do they support live streaming with DRM, key rotation, CMAF Aligned Switching Sets with different keys and possibly different licenses (e.g. for HD or UHD + HD purchase and authorization)?

As to license policy, WAVE and the DRM provider should agree on use cases such as purchase, rental, subscription, geoblocking, blackouts, UHD high security (HDCP2, hardware root of trust …), etc.

My thought is to write down a bunch of DRM use cases, then prioritize and schedule them in terms of WAVE priority and DRM provider ability to support.

A first phase could be those use cases already supported by one or more multiDRM providers, which WAVE can specify in content, device, APIs, and test specs for release at IBC.

Since multiDRM companies support many use cases in production today, and support some level of testing and debugging for most deployments; the rate limiting factor will probably be WAVE’s ability to specify the test cases and the underlying capabilities that need to be specified in content, devices, and browsers.

I suggest we start a GitHub project/document to accumulate DRM use cases. Can someone suggest how and where to do this?

For starters, each basic use case for content and playback would be duplicated with the same content encrypted in the two supported schemes (‘cenc’ and ‘cbcs’), resulting in three sets of test vectors (likely done with dynamic encryption and packaging). (see slides attached).

Each of those tests would be multiplied by the number of DRM systems tested (mostly a function of a player app identifying a device’s supported DRM(s), and formatting license acquisition messages as needed for each DRM system, and the Auth protocol supported by the multiDRM provider).

Each of those “technology” use cases, can be multiplied by various “rights management” use cases, e.g. purchase, rental, subscription, key rotation/reauthorization, hierarchical licenses, regional licenses, just in time license downloads for splices, long and short persistence license storage and retrieval, live, different keys for audio and video, Aligned Switching Sets with different keys, etc.

Each of those test cases can be multiplied by “delivery” conditions, e.g. DASH or HLS manifest, VOD, low latency live, multiple CMAF Chunks per Fragment delivered progressively and delivered multiple Fragments per Segment, broadcast/multicast with occasional return channel, broadcast with no return channel, random access playback or “tuning” of live WAVE Programs.

These are a few use cases off the top of my head, and it is obvious that they are combinatorial and could result in a very long list for each selection of encryption scheme, DRM system, license type, license management, playback scenario (adaptive switch, splice, chunked Fragments), mobile device vs. home theater system using HDMI and external amp and display, and delivery scenarios (VOD, low latency live, dynamic manifests, user targeted ad insertion, broadcast, etc.). We might be able to organize test cases in table form.

Conclusion: We will need to organize and prioritize DRM use cases in order to deliver working specs and tests for some limited scope around IBC timeframe.

KilroyHughes commented 6 years ago

Here is a start at enumerating and prioritizing DRM use cases:

  1. purchase, rental, subscription with license request in advance of playback signaled by manifest
  2. different keys for audio and video Switching Sets downloaded via one or more licenses
  3. license rotation via sample group key change and license download signaled in advance by manifest
  4. hierarchical licenses, e.g. bound Root and dependent Leaf licenses allowing one bound license to enable sets of content for a subscription, channel, region, etc.
  5. domain bound licenses, i.e. bound to a key in a cert that can be installed in multiple devices spanning a user, household, enterprise, region, etc.
  6. broadcast key rotation (periodic root license reauthorization required by leaf licenses delivered in 'pssh' boxes in Fragments)
  7. Event triggered license download when a needKey event is detected with changed KID
  8. Aligned Switching Sets with different keys