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

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