Re: [SUMMARY] Re: Do we need loadSession?

 The current design is based on many discussions and consideration of a
variety of use cases that involve persisting data related to sessions. It
should provide a single solution for all such use cases. We were aware that
the license policy determines whether keys may be persisted and that DRM
system have traditionally relied on this alone. Such systems are supported
by the current normative algorithms.

The group can work on alternative interoperable solutions that address
these use cases, but they need to meet the same requirements. I think it’s
premature to assume that loadSession() is the wrong solution, especially
since there is no complete proposal that addresses the main (key
persistence) use case in a well-defined interoperable way.

Specific comments inline.

On Mon, Jul 28, 2014 at 2:31 PM, Joe Steele <steele@adobe.com> wrote:

> I would like to summarize this thread so far.
>
> There seems to be general agreement that loadSession() is intended to
> solve the problem of sending key release messages when a session was
> previously closed without sending them. The reasoning for persisting the
> original session is to allow the application to store information based on
> the original session ID and send it with the key release message when it is
> eventually sent. Open question — *Is there a better way to accomplish
> this with less side effects?*
>

That is not an accurate statement of the intent. Persistent sessions and
loadSession() were designed to address "Various use cases involving loading
data from storage" <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23955>,
which includes both the offline and the key release use case and
potentially others. It avoids adding one-offs for each such use case. If we
were to decide that persistent sessions/licenses no longer use this design,
we'd need to rethink key release. Preferably, we can solve them together.

Can you clarify what you mean by "side effects"?


>
> There does not seem to be agreement that loadSession() is well suited to
> solving the problem of loading persistent keys. The proposed alternative is
> to load persistent keys on createSession() as the CDM sees fit and provide
> an option to createSession() that forbids the use of persistent keys.
>

Does the proposed alternative assume that we continue to use the
"persistent" sessionType in createSession()? How are these licenses/keys
later removed?

There are still unanswered questions around how to load sessions. "As the
CDM sees fit" is antithetical to interoperability, and such
underspecification may gloss over problems like initData ambiguity.

>
> Joe
>



On Mon, Jul 28, 2014 at 1:57 PM, Joe Steele <steele@adobe.com> wrote:

>
> On Jul 28, 2014, at 1:36 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>
>
> On Mon, Jul 28, 2014 at 1:34 PM, Joe Steele <steele@adobe.com> wrote:
>
>>
>> On Jul 28, 2014, at 9:44 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>
>>
>>
>> On Mon, Jul 28, 2014 at 9:26 AM, Joe Steele <steele@adobe.com> wrote:
>>
>>> On Jul 24, 2014, at 3:39 PM, David Dorwin <ddorwin@google.com> wrote:
>>>
>>> On Thu, Jul 24, 2014 at 3:13 PM, David Dorwin <ddorwin@google.com>
>>>  wrote:
>>>
>>>>
>>>> On Thu, Jul 24, 2014 at 1:03 PM, Jerry Smith (WINDOWS) <
>>>> jdsmith@microsoft.com> wrote:
>>>>
>>>>> Using loadSession to confirm key removal seems like it would be
>>>>> intended to support temporary sessions, not persisted ones.  Is not
>>>>> loadSession limited to reloading stored session data?
>>>>>
>>>> It's important not to confuse "session" and "session data" with
>>>> "license" or "key(s)." Since the confirmation process can fail, a key
>>>> removal-based solution requires the ability to persist the confirmation
>>>> ("session data"). Thus, it must be possible to later load it (i.e. after
>>>> the device has powered off). Whether the license allows the key information
>>>> to be persisted is orthogonal to session persistence.
>>>>
>>>>> I don’t see advantage for using loadSession for the persisted license
>>>>> case.  It requires the app to keep a record of all previously stored
>>>>> sessionIDs and presents a risk of sessions being orphaned and never
>>>>> subsequently reused or removed.  Is there a use case that suggests that
>>>>> stored persisted licenses should not be automatically reused?  And if there
>>>>> is, might it not be equally fulfilled with an attribute on createSession
>>>>> that disallows using a persisted license?
>>>>>
>>>> I think the biggest problem with reuse has been requests for
>>>> persistence and reuse to be invisible to the application. I think your
>>>> proposals help address that. I'm still concerned about lookup based on
>>>> initData - see all the discussions about identifying duplicate initData to
>>>> avoid creating duplicate sessions (in the "temporary" case) - and the
>>>> ability to uniquely identify a session in the event that there might be two
>>>> sessions for the same initData (the current spec prevents multiple sessions
>>>> with the same ID).
>>>>
>>>
>>> [steele] The de-duplication of initData is a concern, but loadSession
>>> puts the burden for this onto the application which has less information
>>> about the relationship between different chunks of initData than the CDM
>>> does.
>>>
>> Yes, the application is responsible for this, but it seems reasonable.
The application is also responsible for storing cookies, etc.

How common is it for applications to want to persist licenses/*content
decryption
*keys?

>
>>>
>>> Also, it's nice to have a single solution for loading persisted
>>> sessions. I suppose the key release model could store the initData with the
>>> sessionId and use the former to retrieve the confirmation. However, you
>>> could imagine a scenario where the same movie is being played and you get
>>> the wrong session. Perhaps that can be solved by never loading the same
>>> session twice at the same time, but it's another example of the issues with
>>> using initData as an identifier.
>>>
>>>
>>> [steele] I don’t believe the concept of a “persisted session” is useful.
>>> The only argument for it seems to be the "failure to release key(s)” use
>>> case. Let me restate the question I asked at the beginning of this thread — *Is
>>> there any use case in which applications would NOT want these messages to
>>> be sent? *I have not seen anyone say “yes" to this question yet. If the
>>> answer is "no", then the question of which key release is tied to which
>>> session is moot.
>>>
>> That may be the only argument for the key release case, but there are
also arguments related to persisting keys - storing a key or license is
essentially persisting part of the session. Regardless, of whether the key
is loaded with something like loadSession(), "persisted session" still
seems useful. As previously discussed, EME is designed around sessions, so
any operations should be related to sessions.

>
>> ​It's not moot if the client application​ needs to associate the key
>> release message with some kind of application-specific session identifier.
>>
>>
>> [steele] Great! This is exactly the type of detail I was looking for. So
>> the application may need to provide a session-specific identifier which is
>> persistent like the key release message. Let’s add that information to the
>> use case wiki as well.  So the real problem here is — the application needs
>> to track some information parallel to the keys being acquired, which it can
>> send along when the keys are released. Is that about right? Are there more
>> requirements on this transaction?
>>
>
> ​That's right. I can't think of additional requirements. The sessionId was
> a mechanism to achieve this.
>
> To further clarify, the information does not need to be in a CDM message,
but the application (or server) wants to be able to associate the message
from the CDM with this information. I've tried to clarify this in your new
wiki text.


>
> [steele] Ok. I added this to the wiki. Now we have to decide if this is
> the best way to accomplish this use case.
>

There is a handshake involved, so remove() must only come after the receipt
has been ack'd. I fixed the wiki to reflect this.

>
> It would be better in my opinion to have a mechanism without as many side
> effects. What is the nature of the information being added? Could the
> application simply accumulate all of the outstanding “tokens” and add them
> all to the next outgoing key release message? This would require the server
> to have a way to match receipts to “tokens” but presumably that is
> completely under the application providers control.
>

Good question, but you still need a way to *later* instantiate a
MediaKeySession object at which to fire the "message" event. This is the Failed
Handshake
<https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Failed_Handshake>
case in the key release section of the wiki.

Note that with loadSession(), there is a single model for loading persisted
data into a MediaKeySession object and there is no need to figure out a new
solution for each unique use case of persisted data from or related to a
session.


>
>>
>>> Any unsent key releases should be sent as soon as feasible. This also
>>> makes the question of which sessions are persistent moot. The sessions that
>>> are persistent are those that contain unsent key release messages. The CDM
>>> can figure out which those are without the help of the application.
>>>
>>
In general, the application should choose to persist data. We wouldn't want
the client (UA/CDM) to silently store a cookie that the application didn't
request.

In the key release case specifically, the CDM must always persist data for
such session in order to support Failed Handshake. The application would
choose to remove the persisted data if the handshake is successful.

>
>>> Another issue is that the same title may not always use the exact same
>>> initData, even in the same file. If we rely on using initData to look up
>>> sessions, it may not always work. This also presents problems if you want
>>> to use initData from, for example, the audio stream to find a license that
>>> was created for the initData from the video stream.
>>>
>>>
>>> [steele] This is yet another reason to have sessions be an ephemeral
>>> construct so there is never any need to look them up.
>>>
>>> If the session is "ephemeral", it should not change the persisted state
of the client (unless some sort of "write" method is called).