Re: [EME] Users of "persistent-release-message" (secure proof of key release for non-persistent licenses)?

On Thu, Mar 19, 2015 at 2:24 PM, David Dorwin <ddorwin@google.com> wrote:

>
>
> On Thu, Mar 19, 2015 at 1:56 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>>
>>
>>   From: David Dorwin <ddorwin@google.com>
>> Date: Wednesday, March 18, 2015 at 4:33 PM
>> To: Bob Lund <b.lund@cablelabs.com>
>> Cc: "<public-html-media@w3. org>" <public-html-media@w3.org>
>> Subject: Re: [EME] Users of "persistent-release-message" (secure proof
>> of key release for non-persistent licenses)?
>>
>>
>>
>> On Wed, Mar 18, 2015 at 2:19 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>>
>>>
>>>
>>>   From: David Dorwin <ddorwin@google.com>
>>> Date: Wednesday, March 18, 2015 at 2:30 PM
>>> To: "<public-html-media@w3. org>" <public-html-media@w3.org>
>>> Subject: [EME] Users of "persistent-release-message" (secure proof of
>>> key release for non-persistent licenses)?
>>> Resent-From: "<public-html-media@w3. org>" <public-html-media@w3.org>
>>> Resent-Date: Wednesday, March 18, 2015 at 2:31 PM
>>>
>>>    Several of the open bugs that have been proposed for discussion at
>>> the f2f relate to "persistent-release-message
>>> <https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-release-message>"
>>> sessions. Other than Mark, is anyone planning to use such sessions in an
>>> application? If so, please reply with information about your use case
>>> before the telecon on March 31, to give the group time to plan for possible
>>> face-to-face discussion.
>>>
>>>
>>>  It would appear that the Limited Concurrent Streams via Key Release
>>> <https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release> requires
>>> the "persistent-release-message" session type. Support for this use case is
>>> important to a number of large service providers.
>>>
>>
>>  Limiting concurrent streams is important to many content providers, but
>> do these large service providers to which you refer use a (persistent)
>> secure proof of key release to do enforce such limitations? For context,
>> there are other ways to enforce concurrency limits, including Limited
>> Concurrent Streams via Key Renewal
>> <https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Renewal>
>> .
>>
>>
>>  Key renewal is an acceptable alternative when the CDM has network
>> connectivity to the license server. What about the case where there isn't
>> network connectivity? In this case the app would want to notify the server
>> of key release once re-connected. Would this be a  persistent-license
>> <https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-license>
>>  or persistent-release-message
>> <https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-release-message>
>>  session?
>>
>
> Can you describe the use case(s) you are thinking about? Specifically,
> what is the reason for lack of network connectivity?
>
> For example, one such use case is offline (i.e. on an airplane). In that
> case (Persisted License / Offline
> <https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Persisted_License_.2F_Offline>),
> the app would download the content to the device and use
> "persistent-license". Both the content and license are persisted locally
> and can be used at any time. The license remains until explicitly removed.
> This can be performed and/or reported to the server next time the user is
> online.
>

​The other use-case (of particular interest to us) is where you want to
avoid an operational dependency on the license servers for ongoing
playback. ​Reduction of operational dependencies is a highly valuable
technique for increasing availability and we have found this approach
empirically very successful.

Note that connectivity and deployment characteristics of license and
content servers may be very different, with content servers available at
the edge of the network and license servers hosted at more centralized
locations. This is of course an architectural choice and different systems
may make different choices, but I think this is a common and valid one.
This diversity in connectivity and deployment characteristics makes
avoiding operation dependencies more important.

…Mark



>
>>
>>>
>>>  Note: This session type specifically relates to persisting a secure
>>> proof of key/license release for *non-persistent* licenses for later
>>> retrieval. It does *not* apply to release messages related to
>>> persistent licenses (“persistent-license
>>> <https://w3c.github.io/encrypted-media/#idl-def-MediaKeySessionType.persistent-license>”
>>> sessions) or even release messages from “temporary” sessions that do not
>>> need to be persisted.
>>>
>>>  David
>>>
>>>
>>
>