Re: [SUMMARY] Do we need loadSession?

Thanks, Joe. This is helpful.

In all of these cases, it seems the application is involved in making this
decision. In #1, the user (via the app) "pins" the content. In #2 (not
combined with #3), the app may proactively acquire licenses on the user's
behalf. In #3, the app could proactively request a license containing all
the keys.

>From an EME POV, #3 is probably most naturally accomplished by requesting
separate licenses for each title, but I can see how that might be
counterproductive to the goal of reducing license server load. Creating a
session with initData containing key IDs (as instructed by the page/server)
for each title might reduce server load (in terms of raw number of
requests). A similar effect could be achieved on the license server, but
that seems like the wrong place, especially if the service wants to
optimize across clients.

If it is reasonable for the application to request (or at least be aware
that it is requesting) persisted licenses, the questions are:

   1. How should the application make the request?
   2. How should the application later retrieve (and eventually remove)
   such licenses?

EME currently has sessionType and loadSession(sessionId), which have
already been used to implement #1 and appear to address Mark's key release
model. #2 and #3 might be more naturally implemented using some type of key
repository, but I don't believe that is consistent with the EME design and
the other application models it supports.

David

On Mon, Aug 18, 2014 at 3:00 PM, Joe Steele <steele@adobe.com> wrote:

> In the last telco I was asked to provide some use cases for persistent
> keys. My earlier comments were entangled with other issues, so I am
> restating here rather than linking to them.
>
> Here are the most common use cases we see for persistent licenses we run
> into:
>
> 1) Offline playback
> Customer wants to download a movie and acquire licenses for playback
> offline, typically while traveling. In this case a license is issued for
> that user on that particular device with a limited lifetime. Possibly with
> a limit on the number of active licenses as well.
>
> 2) Accelerated playback of live streams
> Customer wants to be able to playback a live stream (e.g. a sporting
> event) without having to acquire license right then. In this case the user
> periodically authenticates to acquire a limited lifetime license (e.g. 24
> hours) which allows them to playback content anytime they come back to that
> page until the license expires.
>
> 3) Reduced license server load
> Content publisher wants to lower their cost of deployment for license
> servers. They can do this by issuing a bundle of licenses  with limited
> lifetimes for content which the user _might_ play. This results in fewer
> trips to the license server, since when a title is selected the user may
> already have the required license available.
>
> I will point out that very often 2 and 3 are related. For example during
> popular sporting events, a large number of people will try to get a license
> to view that event moments before it starts. Not only can that make
> acquiring the license take longer for each individual customer, the
> “license storm” of simultaneous requests can take down the server.
>
> Joe
>
> On Aug 4, 2014, at 10:37 PM, Joe Steele <steele@adobe.com> wrote:
>
> I would like feedback from the rest of the group on whether they are or
> will be loading persistent keys using loadSession the way the spec
> describes.
>
> more replies inline —
>
> Joe
>
> On Jul 31, 2014, at 1:10 PM, David Dorwin <ddorwin@google.com> wrote:
>
> The current design is based on many discussions and consideration of a
> variety of use cases that involve persisting data related to sessions. It
> should provide a single solution for all such use cases. We were aware that
> the license policy determines whether keys may be persisted and that DRM
> system have traditionally relied on this alone. Such systems are supported
> by the current normative algorithms.
>
>
> The group can work on alternative interoperable solutions that address
> these use cases, but they need to meet the same requirements.
>
>
> Let’s spell out those requirements. Given that a new one just came out
> (i.e. that applications need to be able to associate local information to
> send along with the key release receipts), I think there is a good chance
> there is still learning to be done here.
>
> As examples of persistent key requirements not being met —
> * Allowing the application to indicate that the CDM should NOT use
> existing content keys and rather acquire new ones
> * Allowing the application to indicate that the CDM should use ONLY
> existing content keys and not acquire new ones
> * Allowing the application to indicate the that CDM may use existing
> content keys or acquire new ones as needed (this could be construed as the
> default now).
> * Allow the application to request a “blanket key release” that indicates
> the CDM does not have any content keys in its possession
>
> I think it’s premature to assume that loadSession() is the wrong solution,
> especially since there is no complete proposal that addresses the main (key
> persistence) use case in a well-defined interoperable way.
>
>
> I don’t assume it is the wrong solution. But it does not seem to be a good
> fit for the way my CDM persists keys and my customers use cached keys.
>
> It seems like you are saying that allowing the CDM to choose when to
> persist keys and load persisted keys in createSession would be a problem
> for interoperability. I believe that it is easier for applications to not
> always have to track what keys the CDM may already have access to. Some
> applications want that level of control (e.g. for key release) but some do
> not. I do not see this as an interop problem. Can you explain what you see
> as a problem?
>
>
> Specific comments inline.
>
> On Mon, Jul 28, 2014 at 2:31 PM, Joe Steele <steele@adobe.com> wrote:
>
>> I would like to summarize this thread so far.
>>
>> There seems to be general agreement that loadSession() is intended to
>> solve the problem of sending key release messages when a session was
>> previously closed without sending them. The reasoning for persisting the
>> original session is to allow the application to store information based on
>> the original session ID and send it with the key release message when it is
>> eventually sent. Open question — *Is there a better way to accomplish
>> this with less side effects?*
>>
>
> That is not an accurate statement of the intent. Persistent sessions and
> loadSession() were designed to address "Various use cases involving
> loading data from storage"
> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23955>, which includes
> both the offline and the key release use case and potentially others. It
> avoids adding one-offs for each such use case. If we were to decide that
> persistent sessions/licenses no longer use this design, we'd need to
> rethink key release. Preferably, we can solve them together.
>
>
> Can you clarify what you mean by "side effects”?
>
>
> The idea of what is in a session and how it is handled by the CDM is still
> too fuzzy:
> * We know they MAY have key release receipts, assuming the CDM supports
> them.
> * We know they MAY have keys
> * They may contain other data as well (status, policies, etc.).
> * When the application asks for the session to “persist” this may or may
> not mean anything to the CDM
> * If CDM does persist the session, it may or may not contain any keys.
> * When remove() is called on a session, the exact data that is removed
> (aside from keys) is up to the CDM
>
> I was not opposed to the definition of a session being fuzzy when it was
> an ephemeral construct like a TLS session. I think that is a natural
> outcome of the CDM and key server being out of scope. But this fuzziness
> means that expectations around CDM behavior when someone calls
> loadSession() or remove() are unlikely to be met across all or even most
> CDMs.
>
>
>
>>
>> There does not seem to be agreement that loadSession() is well suited to
>> solving the problem of loading persistent keys. The proposed alternative is
>> to load persistent keys on createSession() as the CDM sees fit and provide
>> an option to createSession() that forbids the use of persistent keys.
>>
>
> Does the proposed alternative assume that we continue to use the
> "persistent" sessionType in createSession()? How are these licenses/keys
> later removed?
>
>
> If we keep the loadSession method, then having “persistent” continues to
> make sense as a signal to the CDM that the application may be retaining
> information about this session. If not — I would eliminate it as being
> unclear.
>
> I would expect that CDMs will naturally remove keys/license if they
> expire. We could provide an explicit mechanism for clearing data (e.g.
> MediaKeys.clearData). I am not sure applications would use such a
> mechanism, but we could provide it.
>
>
> There are still unanswered questions around how to load sessions. "As the
> CDM sees fit" is antithetical to interoperability, and such
> underspecification may gloss over problems like initData ambiguity.
>
>
> The details of key acquisition are deliberately left to be defined between
> the CDM and license server. This is one of the strengths of the standard
> and I thought was a great compromise. I am not sure what you are referring
> to when you say “initData ambiguity”. Would you mind clarifying?
>
>
>
>> Joe
>>
>
>
>
> On Mon, Jul 28, 2014 at 1:57 PM, Joe Steele <steele@adobe.com> wrote:
>
>>
>> On Jul 28, 2014, at 1:36 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>
>>
>>
>> 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.
>>>>
>>> Yes, the application is responsible for this, but it seems reasonable.
> The application is also responsible for storing cookies, etc.
>
> How common is it for applications to want to persist licenses/*content decryption
> *keys?
>
>>
>>>>
>>>> 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.
>>>>
>>> That may be the only argument for the key release case, but there are
> also arguments related to persisting keys - storing a key or license is
> essentially persisting part of the session. Regardless, of whether the key
> is loaded with something like loadSession(), "persisted session" still
> seems useful. As previously discussed, EME is designed around sessions, so
> any operations should be related to sessions.
>
>>
>>> ​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.
>>
>> To further clarify, the information does not need to be in a CDM message,
> but the application (or server) wants to be able to associate the message
> from the CDM with this information. I've tried to clarify this in your new
> wiki text.
>
>
>>
>> [steele] Ok. I added this to the wiki. Now we have to decide if this is
>> the best way to accomplish this use case.
>>
>
> There is a handshake involved, so remove() must only come after the
> receipt has been ack'd. I fixed the wiki to reflect this.
>
>>
>> It would be better in my opinion to have a mechanism without as many side
>> effects. What is the nature of the information being added? Could the
>> application simply accumulate all of the outstanding “tokens” and add them
>> all to the next outgoing key release message? This would require the server
>> to have a way to match receipts to “tokens” but presumably that is
>> completely under the application providers control.
>>
>
> Good question, but you still need a way to *later* instantiate a
> MediaKeySession object at which to fire the "message" event. This is the Failed
> Handshake
> <https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#Failed_Handshake>
> case in the key release section of the wiki.
>
> Note that with loadSession(), there is a single model for loading
> persisted data into a MediaKeySession object and there is no need to figure
> out a new solution for each unique use case of persisted data from or
> related to a session.
>
>
>>
>>>
>>>> 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.
>>>>
>>>
> In general, the application should choose to persist data. We wouldn't
> want the client (UA/CDM) to silently store a cookie that the application
> didn't request.
>
> In the key release case specifically, the CDM must always persist data for
> such session in order to support Failed Handshake. The application would
> choose to remove the persisted data if the handshake is successful.
>
>>
>>>> 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.
>>>>
>>>> If the session is "ephemeral", it should not change the persisted state
> of the client (unless some sort of "write" method is called).
>
>
>
>
>