Re: Clarifying key types and persistence

I missed commenting on the other bits in my earlier email —  more comments inline:

Joe

On Apr 4, 2014, at 3:52 PM, Joe Steele <steele@adobe.com> wrote:

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

The per-origin requirement was driven by EME privacy requirements, not by DRM requirements. See Section 7.1.3 Tracking. 

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

Mainly Flash and Silverlight players. I believe there is a Marlin plugin as well which would support this key model, but I do not have personal experience with it. I believe the FairPlay support available via Safari (out of scope for this spec - I know) also supports key chaining. Without talking about specific customers implementations I don’t think I can share any more details, but that should be sufficient. 

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

Bug 25902 is a good example of this. Bug 25200 is more of an example of my position I think. The behavior will be entirely key system and license server dependent, but it allows the app to try something and see if it works. None of the API changes I am suggesting are more than that. I am not intending to require a particular CDM to support a key model. But I would like these key models to be supportable, since they are very useful in my opinion. 

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

If that was/is the intent - then the spec should be rewritten to clearly state that. That was not my takeaway from the spec itself or conversations about this in the various telco’s I have been in. Nor have I seen this articulated elsewhere.

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

See my comments above about what drove this choice. However I did not mean to imply that the provisioning process uses the origin directly. What I was saying is that the provisioned keys are per-origin. I.e. http://player.foo.com and http://player.bar.com will each have their own key for requesting licenses. 

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

Domain keys allow a further level of abstraction from the license server. For example a collection of cooperating content providers can all share a service for managing domain membership. The user benefits by having one place to go to manage the set of devices for multiple service providers. The businesses benefit by not having to each maintain a device management service. 

Another user-facing use case is the ability to side-load licenses. Using domains, you can acquire licenses which will play on any player in the domain and then transfer those licenses between players as needed. This enables people who want to be able to backup their licenses in case a device goes dead.

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

Are you asking whether two key systems can both use domain keys for the same content? The answer is yes. The license servers will know based on the type of request they get which key system is being used and therefore which domain key to use. This workflow is currently used for Ultraviolet players for example based on Flash or Silverlight. 

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

The content key could be embedded in the content (e.g. in the PSSH) or provided as a separate HTTP download. The goal is to avoid hitting a license server, not necessarily to avoid any network traffic. Obviously in the streaming case we are still downloading the content itself. 

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

(0) is completely independent of (1) or (2). In the domain case, the content key is delivered the same way as a normal player-bound key is delivered. But instead of the keys being tied directly to that player they are tied to a key shared by several players.