Re: Secure release and persistence

On Tue, Apr 28, 2015 at 12:07 PM, Jerry Smith (WINDOWS) <
jdsmith@microsoft.com> wrote:

>  This makes sense to me, Mark.  You are looking for markers to bound the
> usage of keys so that keys used for extended playback can be distinguished
> from keys used to start, but not watch content.  Persisting first and
> latest decrypt times accomplishes this.
>

I'm not sure what you're referring to with these two types of keys, but I
don't think Mark has mentioned anything about different types of keys. As
far as I know, the Netflix use case is for a single key used for the entire
duration of the content. Clearly, there is still a lot of confusion (on one
or both of our parts) about what exactly this feature is and what it is
used for.

>
>
> Jerry
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Tuesday, April 28, 2015 8:02 AM
> *To:* public-html-media@w3.org
> *Subject:* Secure release and persistence
>
>
>
> All,
>
>
>
> Hopefully this will catch you in your newly-freed "EME hour" :-)
>
>
>
> As promised at the F2F I will draft spec updates this week to fill in the
> missing details of this feature. However, I would like to make one
> significant change in response to comments at the F2F and previously
> regarding exactly what is persisted.
>
>
>
> The spec describes persistence of a "record of license destruction". Aside
> from the fact that we have no concept in our spec of "license", this is not
> typically how this feature is implemented in DRMs and suggests a need to
> persist data at close / shutdown / crash or other events that cause license
> destruction.
>
>
>
> In practice, what is persisted  is a record of available keys at a point
> in time. This is updated regularly *during streaming*. There is no update
> on close / shutdown / crash. In a later browsing session, this record is
> compared with the actually available keys and a discrepancy is taken as
> evidence that keys were destroyed.
>
>
>
> I propose that we describe this persisted data explicitly as "for each key
> in the session, the *first decrypt time* and the *latest decrypt time*".*
>
>
>
> Are there any comments on that before I implement it ?
>
>
>
> Based on this change in description, I suggest we call this session type "
> *tracked*" - or something similar - since really we are 'tracking' the
> usage of keys. This name will also invite appropriate scrutiny of the
> persisted data properties.
>
>
>
> ...Mark
>
>
>
> * there may of course be other CDM-specific information persisted and
> included in the release message. For example if the CDM has a concept of
> licenses, then license correlation identifiers may be present. Also, how
> the CDM communicates time in its messages may be CDM-specific.
>
>
>
>
>
>
>