W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

Re: Clarifying key types and persistence

From: Joe Steele <steele@adobe.com>
Date: Fri, 4 Apr 2014 22:52:17 +0000
To: David Dorwin <ddorwin@google.com>
CC: "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-ID: <BBC1BB1F-BA97-4EFE-8F62-5759747EBB4A@adobe.com>
I tried to point out several reasons why keys delivered often belong to a hierarchy of keys. It basically boils down to performance or business reasons. There is content available today and more coming online which relies on a hierarchy of keys being available. 

I donít see how the model you are pointing to precludes what I am describing. The question seems to boil down to - what keys does the application have to deal with? I believe the application has to deal with two types of keys - content keys and domain keys. Both of those can require action by the application. None of the other key types require action by the application. 

BUT ó we should not design the APIs in such a way that those other types of keys cannot be used. Several recent proposals seem to be tightening key usage to the point where they will exclude participation by content providers with business models that require them. Even if we decide that we donít want to support some of this functionality right now, I donít want to see the spec defined in such a way that would make it difficult to add support in the future without killing backwards compatibility.

Joe

On Apr 4, 2014, at 9:49 AM, David Dorwin <ddorwin@google.com> wrote:

> 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 hierarchy."
> 
> Other questions and comments inline.
> 
> On Thu, Apr 3, 2014 at 4:30 PM, Joe Steele <steele@adobe.com> wrote:
> On Apr 2, 2014, at 1:01 PM, David Dorwin <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 and bug bug 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)? 



Received on Friday, 4 April 2014 22:52:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC