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

Other questions and comments inline.

On Thu, Apr 3, 2014 at 4:30 PM, Joe Steele <> wrote:

> On Apr 2, 2014, at 1:01 PM, David Dorwin <> 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<>and bug bug
25200 <> are examples
of attempting to provide consistent and expected behavior across

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

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

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

Received on Friday, 4 April 2014 16:50:27 UTC