Re: Clarifying key types and persistence

Comments inline —

TL;DR:
* Keys delivered often belong to a hierarchy of keys
* Keys at different levels of the hierarchy have different lifetimes
* Applications may or may not need to be aware of this hierarchy

Joe

On Apr 2, 2014, at 1:01 PM, David Dorwin <ddorwin@google.com> wrote:

> Thanks for summarizing the types. Comments inline.
> 
> On Tue, Apr 1, 2014 at 2:34 PM, Joe Steele <steele@adobe.com> wrote:
> In the call today it became clear there still seems to be disagreement over what types of keys should be supported by the Encrypted Media specification.  
> 
> We have had lots of discussion on sharing keys between domains and app instances:
> http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0022.html
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202
> 
> We have had lots of discussion on storing keys persistently:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19785
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
> 
> These are the types of keys I see in common use:
>   Key system keys:  Keys that are common across many instances of the key system, not bound to a particular application or device. 
> 
> Can you provide more details? Is this something like a global key for all implementations of the DRM? Do applications need to be aware of this?

Yes, these are global keys. No, I don’t think applications need to be aware of them. I mention them because they may be cached and/or updated as a result of EME operations and that needs to be explicitly allowed. 

> 
>   App and device keys:  Keys that are bound to a particular device and/or application. 
> 
> 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'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.

> 
>   License chaining keys:  Keys which are used to derive or unwrap content keys. One example would be  domain keys as used by Ultraviolet. 
> 
> This seems to be the primary unaddressed issue, but I don't think there has been a comprehensive presentation or discussion of the use cases. It's unclear whether and how these should work in the web platform.

These do work in the web platform today. I believe with fairly small changes to the current spec, we can ensure consistency on how they work across applications.

> 
>   Content keys:  Keys used to directly encrypt content.
> 
> These are the keys that the EME APIs have been designed around since the first draft. All key systems and common encryption media streams use them. Each Key is associated with a key ID and lives in a single MediaKeySession. initData identifies (possibly indirectly) the key ID(s) that should be in the resulting license.

> 
> There seems to be disagreement in the group about which of these key types should be supported. Some of these keys are required for the underlying key systems to function at all. Some of these keys enable business models. Some of these keys are for improving performance. All of these keys have legitimate uses when playing back streaming encrypted content. Supporting all of these key types is within the architectural model of the EME spec. 
> 
> 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. 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.

The main change visible to applications would be the ability to manage keys independent of session (bug#25218), which for some keys I believe makes sense. We have a standard way of referring to keys (key ID) so this does not need to be key system specific at all. 

> 
> The issue of key storage is linked to the issue of supporting non-content keys, as those keys may have a different lifetime than content keys. Key acquisition can be costly in various ways and minimizing the number of key acquisitions is generally a good thing. 
> 
> It would be helpful to understand these issues and where/why they occur. It would also help to better understand the types of keys above.
> 
> The goal should be to minimize the *total* time spent acquiring keys for a given use case - whether that's one key or 10 keys is irrelevant.

I agree about the total time (both client and server). However the number of keys acquired may be very relevant to some DRM systems as it may directly impact the time it takes to acquire keys. The types of keys acquired may also be very relevant.

> 
> I propose the following changes to Section 1.1.3 “Key Session” to clarify things.
> 
> Spec text specifying that sessions refer to the in-memory representation:
> “A Key Session, or simply Session, represents the lifetime of the _in-memory representation_ of any license(s)/key(s) it contains and associates all messages related to them.”
> 
> In the telecon, you said that a session might contain both content keys and other keys. I think a session should only contain a single type of key(s). This eliminates issues like needing to access each key individually. (How keys in one session might use other keys is TBD pending further discussion.)

In general when talking about chained keys:
* the application may have no knowledge of root keys
* the CDM does not know a root key is required until a content key is encountered that requires it
* the CDM can only signal to the application that it needs a root key via a key request
* root keys are non-content keys by the definition above 

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. 

> 
> 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. 

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. 

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 

The player needs to be able to acquire the library keys to playback content. It also needs to be able to cache them in order to realize the performance benefits. These keys are non-content keys. 

> but we should not start from an assumption that legacy DRM systems should be exposed as-is to JavaScript.

There are systems and standards being developed today which use these key types for reasons which are relevant to web-based players using EME. The Ultraviolet domain key usage is a great example. We need a way to support it (or at least not exclude it). These key types are used not because some legacy DRM required it, but because performance needs and/or business models required it. 

> The two key systems known to have shipped so far - Widevine and PlayReady - have implemented new interfaces and/or wrappers to meet the requirements of EME and the web platform. It is reasonable to expect that other systems will need to make similar adaptations.

Primetime/Access DRM has made similar adaptations to fit under the EME APIs. This is not an issue of DRMs making adaptations to fit under the existing model. There is text in the spec today (referenced above) which could be interpreted to exclude large swathes of useful functionality that could otherwise fit under the API surface exposed for EME. That is what I am trying to correct. 

> 
> 
> Joe 
>