Re: Do we need loadSession?

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

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.

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.

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