Re: Do we need loadSession?

There were some issues with the latest wiki updates. I've updated the key
release section with more detailed information on how it is intended to
work with the current spec text.

Please see specific comments inline below.

On Thu, Jul 24, 2014 at 11:15 AM, Mark Watson <watsonm@netflix.com> wrote:

> Jerry, Joe,
>
> Please see comments in line in response to both mails...
>
>
> On Thu, Jul 24, 2014 at 10:48 AM, Jerry Smith (WINDOWS) <
> jdsmith@microsoft.com> wrote:
>
>>  It’s not obvious how loadSession would help clean up when sessions are
>> not closed properly.  Can anyone confirm this is an intended purpose and
>> explain it further?
>>
>
> ​Yes. Consider the case where a session is closed (and the key release)
> but there is no chance to send the proof of key release message (e.g.
> window tab closed during playback)​. Next time the application is loaded,
> we would like to be able to retrieve the session in the 'key released'
> state and have the proof of key release message exchange take place then.
> The application will be able to store the session ID (e.g. in IndexedDB)
> for all sessions with a pending key release message exchange and retrieve
> them with loadSession.
>

See the updated wiki section for more details.

>
>
>>
>>
>> I believe loadSession was added as part of the persisted licensing model
>> in EME.  To persist a license, apps call createSession as persistent,
>> session data is then stored, and loadSession exists to re-use stored
>> sessions, including keys.  Apps need to have a way to track when session
>> data is stored, and must request it be re-used.  There is also a method to
>> remove the stored session data.  This approach gives apps control over when
>> data is persisted, the type of license desired, and when that license gets
>> re-used.
>>
>
> ​Yes, that's another use-case for loadSession.​
>
>
>>
>>
>> This model doesn’t align well with DRM systems that have the license
>> server control whether the license is persistent or not.
>>
>
> ​If the persistent attribute controls session persistence, then license
> persistence can still be under server control. ​
>

Agreed. The "persistent"/loadSession() model doesn't exclude such DRM
systems, it just requires that the server and application are in sync. This
helps avoid unexpected behavior, which might lead to licenses unknowingly
being left on the client.

>
>
>>   I believe it is also common for these to re-use persisted licenses
>> automatically.  This suggests we should consider changes that allow
>> persisted licenses to be re-used on createSession, and perhaps also support
>> the proposal you make to add an attribute to createSession to control
>> whether this is done or not.
>>
>
> ​I don't mind changing back to that model, so long as there is a way to
> retrieve the persisted proof of key release messages and know which earlier
> sessions they are associated with.
>

One of the goals of the loadSession() model was to be flexible and cover
multiple use cases. Loading keys/licenses from createSession() has been
discussed multiple times. Loading a session and being explicit about it is
an improvement over previous proposals, but I still think it is problematic
(see my last comment below).

>
> ...Mark​
>
>
>
>>
>>
>> Jerry
>>
>>
>>
>> *From:* Joe Steele [mailto:steele@adobe.com]
>> *Sent:* Thursday, July 24, 2014 10:25 AM
>> *To:* <public-html-media@w3.org>
>> *Subject:* Do we need loadSession?
>>
>>
>>
>> Before the last telco, Mark Watson raised an issue with the Key Release
>> use case described on our wiki (
>> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Limited_Concurrent_Streams_via_Key_Release).
>> He called out the confusion between the idea of a session and the idea of
>> persistent licenses. Per our discussion in the telco - I have since updated
>> the wiki to reflect this.
>>
>
As mentioned above, I updated this section.

>
>>
>> The loadSession() method appears (based on comments from the editors) to
>> have been added primarily to support the key release use case by allowing
>> the CDM to “clean up” when a session was not closed properly. However I am
>> concerned that as defined it is too general and impacts key usage as well.
>>
>
The "persistent" sesisonType and loadSession() were added to address
multiple use cases related to persisting. This includes secure proof of key
release and persisted licenses.

>
>>
>> Here are my questions:
>>
>>
>>
>> *Is there any use case in which applications would NOT want “cleanup”
>> messages to be sent?*
>>
>> If this answer is NO (I believe it is), then I suggest we remove
>> *loadSession* and simply require CDMs to send any outstanding “cleanup”
>> messages for this application when the next *createSession* is called.
>>
>
> ​The question is then how the application know which earlier sessions the
> proof of key release messages are associated with.​ This is necessary to
> associate those messages with the application's identifier for the
> (original) session.
>

See the updated wiki section for usage. We shouldn't hide side effects in
other methods. loadSession() allows the application to be in control (as is
the case for the association Mark mentions) and know what to expect (it's
specified in the normative algorithms).

>
>
>>
>>
>> *Is there any use case in which applications would NOT want cached
>> licenses to be loaded? *
>>
>> If this answer is YES (I believe it is), then I suggest we allow that to
>> be specified when *createSession* is called. This would be complementary
>> to the current “persist” flag that indicates whether the application wants
>> to allow license caching. This is something that others have expressed a
>> need for as well (
>> http://lists.w3.org/Archives/Public/public-html-media/2014Mar/0020.html).
>>
>>
>>
>> These two changes would simplify application development by removing the
>> need to track the sessionID (which should be a temporary value) and
>> simplify CDM implementation by allowing them to manage cached licenses in
>> the way most appropriate for their licensing models.
>>
>
This would require identification of sessions by initData, which is more
difficult, may not uniquely identify sessions, and is inconsistent with the
rest of the session model.

>
> ​From the beginning it has been the case that sessionID needs to be unique
> across browsing sessions if you support secure proof of key release.
>
> ...Mark​
>
>
>
>>
>>
>> Joe Steele
>>
>
>