Re: [EME] Updated proposal for secure proof of key release

I think we also need to address https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622

I will provide text for the FAQ answer.

As for requesting old sessions, I think we need to explicitly introduce the idea that CDMs may persist sessions and so createSession() may retrieve a preexisting session based on the type and initData. If the provided type/initData match multiple pre-existing sessions, then any one is returned (and so if they are both null, than any pre-existing session is returned). We should also ask that a keymessage is always sent (even if it might be null) when the session is created so that the user script has some indication when the sessionId is assigned.

…Mark

On Jan 14, 2013, at 6:19 PM, David Dorwin wrote:

Mark and I discussed this and agree that we should try to reuse as much of the base algorithms as possible. Mark would also like a consistent way to retrieve saved key sessions and a FAQ answer. Therefore, I propose the following tasks for resolution for this bug:

  *   Generalize createSession() algorithm so proposed 4.5.1 is covered by it. There are a few statements that assume generation of licenses.
  *   Figure out where to document how to request old sessions, if supported.
  *   Add a FAQ entry about how key release could be supported, similar to the entry for heartbeat.

I’ve started working on the createSession() changes.

David

On Fri, Jan 11, 2013 at 6:10 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
Hi David,

Please see inline …

On Jan 11, 2013, at 10:07 AM, David Dorwin wrote:

Hi Mark,

The more I think about key release, the more I think it should not be included in the spec.

Key management, policies, message protocol & structure, and key-system or CDM-specific details have been intentionally left out of the spec. As an example, even the key replacement algorithm is not specified. Key systems are free to define protocols that include a variety of messages as long as they fit within the defined APIs (primarily update() and keymessage). Heartbeat, license renewal, key rotation, etc. can all be implemented within the existing framework but are not included in the spec.

The key release proposal does not require altering the existing APIs or the defined algorithms. It simply defines additional key management, policy, parameter values, and messages, all of which are key system-specific. As with the basic message flow, heartbeat, etc., I expect that key systems will eventually converge on a set of best practices, but these are not usually defined in a standards-track spec.

The proposal does expose functionality at the API level and it's not all just key-system specific.

Specifically, the concept of "sessions" and "sessionIds" is an API concept, not a key-system-specific one. We say that anything that goes on *within* a session is keysystem-specific. For example, the number of message exchanges, when they occur in the session, what they do in terms of keys etc. Heartbeat and key rotation are both examples of where - within a session - some keysystem-specific magic can go on.

But the notion of a session itself is part of our API. We define how you create them in a key-system-specific way. They're created from a keysystem-independent object (the initData - although within it there may be multiple keysystem-specific parts).

The key part of the secure proof of key release proposal is that it is possible, from outside any session, to retrieve information related to pre-existing sessions. We're adding a new way to interact with the CDM outside the context of a session. I don't see how we could do that within the existing API.


Finally are there implementors and CDM providers that intend to support this? Are there any content providers besides Netflix that intend to use it?

Those are good questions. If the answer to the first one is no when we get to the appropriate milestones in the specification work, we'll have to pull this out. Just like anything else.

I'm not really empowered to speak on behalf of CDM implementors, but I know that it's not pointless putting this in the specification now.

…Mark


I do not think a Working Draft should include a feature where the answer to the above questions is "no", especially when it adds non-trivial complexity to implementations.

Regards,
David

On Fri, Jan 11, 2013 at 9:10 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

An updated proposal is attached.

I'd like to propose that we include this text in the First Public Working Draft.

[It need not be Section 4, as written, since this interrupts the flow of the rest of the document. I leave it to David to suggest the best place for it.]

…Mark