Re: Do we need loadSession?

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

​It's not moot if the client application​ needs to associate the key
release message with some kind of application-specific session identifier.


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