Re: Do we need loadSession?

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. 

> 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. 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.

> 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.

>  
> 
> 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> 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
> 
>  
> 
>  
> 
> 
>