Re: Secure release and persistence

Mark,

Are you also proposing that there be visibility into this persisted data?
If so — would it make sense to extend the existing key status mechanism to include this kind of information, and then persist that structure?

Joe

> On 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.
> 
> Jerry
> 
> From: Mark Watson [mailto:watsonm@netflix.com <mailto:watsonm@netflix.com>]
> Sent: Tuesday, April 28, 2015 8:02 AM
> To: public-html-media@w3.org <mailto: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.