RE: Do we need loadSession?

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?

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?

Jerry

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Thursday, July 24, 2014 12:10 PM
To: Mark Watson
Cc: Jerry Smith (WINDOWS); Joe Steele; <public-html-media@w3.org>
Subject: 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<mailto: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<mailto: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<mailto:steele@adobe.com>]
Sent: Thursday, July 24, 2014 10:25 AM
To: <public-html-media@w3.org<mailto: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