RE: Clarifying key types and persistence

These discussions are making it very obvious that EME is pushing more and more knowledge about the CDM internals into the application. The original goal was to make it as transparent as possible and as DRM-implementation independent as possible. This goal is hard to achieve since DRMs are typically very complex including the key hierarchy that Joe mentioned (but that is just one example).

All of this can be kept at an abstract level and CDM independent if most of the functions are actually performed by the CDM internally with minimal involvement of the application.

This was the main reason why we and others have been advocating from the very beginning the need for an out-of-band channel that can be utilized by the CDM in order to leave the application out of the complexities. This is how several CDMs in the field work today and the applications using them stay simple and focused on their main functions (rather than understanding the intricacies of individual CDMs).

Maybe this is time to revisit the exclusion of OOB channel decision.
          Thanks,
                   Petr


From: David Dorwin [mailto:ddorwin@google.com]
Sent: Friday, April 04, 2014 9:50 AM
To: Joe Steele
Cc: <public-html-media@w3.org>
Subject: Re: Clarifying key types and persistence

Thanks for the reply. I'm still looking for the problem that these scenarios seek to solve. For example, why do "Keys delivered often belong to a hierarchy of keys"? The one clear problem statement I found was "not having to acquire licenses for each new piece of content..." I can clearly see how that improves the user experience, but it's also quite different from the model<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/stack_overview.svg> EME was designed around, so we should consider how it fits in overall, especially if "Applications may or may not need to be aware of this hierarchy."

Other questions and comments inline.

On Thu, Apr 3, 2014 at 4:30 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
On Apr 2, 2014, at 1:01 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:

Are you referring to individualization or provisioned keys? This hasn't been discussed, but I think such keys should be the responsibility of the user agent and outside the EME APIs (assuming it is per device and there are still appropriate safeguards and notifications).
I should have clarified that this assumes the individualization or provisioning is per-device and performed by a user agent-approved server. In other words, it is not performed by the player or any origin the user visits. Such scenarios would likely need different solution.

I'm not sure what an "app" key is or how that fits in the web platform. I would not apply the same logic to such keys at this time.

I am referring to provisioned keys. They may be per device or per device+origin combination. Again I mention them because they may be cached and/or updated as a result of EME operations and that needs to be explicitly allowed.

Why would keys need to be provisioned per device+origin combination? See the comments in (0) below.

It's not currently clear that all of these types are consistent with the web platform or the purpose of EME, which is to allow applications using it to work across platforms in a consistent and expected way that is compatible with the web platform, including its security and privacy model.

Many browser players today use the key types described above for decrypting content.

Can you provide examples? Are you referring to players built in Flash?

I am not sure what you mean by consistent here. If you mean that those applications should be able to use a standard API between browsers, I agree whole heartedly and think with minor changes to the spec would be possible. I don’t believe these changes have significant new security or privacy implications for EME.

I mean that the behavior should be as consistent across user agents, platforms, and key systems as possible. It's not enough for the API signature to be the same - many browser incompatibilities have had nothing to do with the API. That's why the W3C requires tests for interoperability. Because of the nature of DRM, EME is unique in that the exact messages are not specified. However, we should still aim to be as consistent and interoperable as possible. This is hard, and even with the current narrow definition of a key, there are already issues with incompatible implementations or reliance on proprietary mechanisms causing problems for app developers.

Bug 25092 comment 1<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c1> and bug bug 25200<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200> are examples of attempting to provide consistent and expected behavior across implementations.

The design of EME assumes there may be multiple key requests generated during a session. This implies that those keys may be dependent on one another e.g. in a hierarchy. Based on previous conversations where I brought up the issue of domain keys, I assumed this was widely understood.

I don't agree that this is implied. The original intent was simply to allow multiple rounds of challenge-response, if necessary.


Spec text defining the relationship of keys to a Key Session:
“A Key Session may contain one or more keys. Keys may be identified by key IDs.”

Spec text acknowledging that non-content key types may be supported by the CDM:
“Keys acquired during the lifetime of a Key Session may be directly or indirectly used in decrypting content.”

Spec text acknowledging that keys may be cached by the CDM if allowed by the browser:
“Any keys acquired by the Key System during the lifetime of a Key Session may be stored as needed by the Key System and allowed by the User Agent.”

This seems like a good topic to hash out a bit before we get to the F2F next week. I don’t think I am saying much that is new here. We have enough bugs filed around different aspects of this subject (17202, 17750, 25200, 25217, 25218, etc.) that I don’t feel the need to file another. However let me know if you think that is not the case.

As I mentioned above, I'd really like to see the web use cases documented, not just the legacy solutions or perceived API gaps. We should evaluate use cases and how they fit into EME and the web platform,

I agree about the use cases. Here are a few which have been mentioned before but I will re-phrase for clarity. If you can point me to good location to publish these use cases, I will put them there. All of these use cases are supportable under EME. But unless some changes to the spec text happen, these will be supported by non-standard extensions to the spec or non-compliant behavior by the CDM.

0) Streaming content bound to a device and origin

In this use case streaming content is delivered encrypted with keys that are tied to a specific device and origin (i.e. player application origin). The player has to be able to request provisioning of the individualized key. This request could be done by the user agent directly, but that would break the current model of directing all network requests through the application. Ideally this should not happen until application is relatively sure content is going to be played because of performance and cost concerns. EME needs to allow for those keys to be requested and cached independent of the content keys that depend on them. These keys are non-content keys.

The key is bound to an origin like https://player.example.com? That seems difficult to ensure in a browser.
What are the advantages of provisioning a key for the device-origin combination? Why not use some other cryptographic mechanism that doesn't require another provisioning? Would key derivation based on origin not be sufficient?

1) Streaming content bound to a user domain

In this use case streaming content is delivered encrypted with keys that are tied to a user account and a domain key. The player has to be able to both join and leave licensing domains. This process should be driven by the application, but because key system specific keys may be delivered as part of this process, EME needs to allow for those keys to be requested and cached independent of the content keys that depend on them. This is analogous to the Ultraviolet key model, but is not limited to Ultraviolet. These keys are non-content keys.

What is the advantage of a domain over server-managed implementations of the same policies? Or, what user-facing use cases does it enable?

Can this work across key systems? Does it still make sense in that case?

2) Streaming content bundled into libraries

In this use case the user is able to select content organized in libraries (e.g. by studio). Each library is encrypted with content keys which are bound to a common library root key.

This can be done for many reasons, but here are a few common ones:
* the content provider needs to be able to disable a library of content for everyone (usually for contractual reasons)
* the content provider needs to be able to disable individual library access for a user (usually because of service changes)
* the player gets a significant performance boost from not having to acquire licenses for each new piece of content once the library is acquired

Does this assume that the content key is delivered (encrypted with the library key) with media data? Is it embedded in the media data or media resource?

Is the same true for (0) and (1)?