W3C home > Mailing lists > Public > public-html-media@w3.org > April 2015

Secure release and persistence

From: Mark Watson <watsonm@netflix.com>
Date: Tue, 28 Apr 2015 08:02:09 -0700
Message-ID: <CAEnTvdBSDHrs8va98R89Yjs++og2pN2Pn3bia4uZhPjGxeTgeQ@mail.gmail.com>
To: "public-html-media@w3.org" <public-html-media@w3.org>
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.
Received on Tuesday, 28 April 2015 15:02:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 April 2015 15:02:42 UTC