Re: Do we need loadSession?

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

...Mark​



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