W3C home > Mailing lists > Public > public-html-media@w3.org > March 2014

RE: [EME] Persistent license

From: Maruyama, Shinya <Shinya.Maruyama@jp.sony.com>
Date: Wed, 12 Mar 2014 00:46:23 +0000
To: Mark Watson <watsonm@netflix.com>
CC: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <E7496ED336482E459A47A005EAE8161201C218@JPYOKXMS121.jp.sony.com>
You mean whether to load persistent license in createSession is not specified explicitly but is already left to CDM implementation, right?
I think between these two options; i.e. explicit loading by loadSession and implicit loading by createSession, there should be an another difference we should take care of.

As for loadSession, I assume that application can implement two different scenarios;
- In case of download file based playback, application calls loadSession to avoid unnecessary license acquisition.
- In case of streaming, application calls createSession to acquire license for every playback. In this case, application may expect createSession not to load persisted license regardless of availability of persistent licenses. Unexpected use of persistent license should be avoided especially for the streaming case because it may cause unexpected sequence for the service which may expect to receive license request for every playback

If we implement implicit license loading  by createSession, we can't implement the latter scenario above because it is impossible to switch whether to load persistent license in createSession at runtime.

This is why I propose to use 'persistent' attribute which enables createSession to switch the behavior at runtime.


From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Wednesday, March 12, 2014 8:38 AM
To: Maruyama, Shinya
Cc: public-html-media@w3.org
Subject: Re: [EME] Persistent license

I think the intention was that if a CDM supports persistent licenses and when you do a createSession it finds an already persisted license that is appropriate for this content, then it can use that persisted license. The difference between createSession and loadSession is that createSession specifies what it needs with the initData wheras loadSession specifies what it needs with a sessionId.


On Tue, Mar 11, 2014 at 4:21 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote:

What do you think of loading license by createSession with using 'persistent' attribute'? Do you think there is still room to discuss whether to support this as another option to load persistent license or even as a substitute for existing loadSession?
I suppose there are some disadvantages on current loadSession.
- Using sessionId requires application to store sessionId beyond the lifetime of the session, which looks a bit weird semantically
- Application need to use some identifier; e.g. KIDs, initData, a content identifier obtained in out-of-band way etc, to retrieve the sessionId after all.

I suppose David's proposal for 'persistent' attribute in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c10 would provide us with solutions for these disadvantages and moreover consistent EME API for the 'persistent' license usecase.


From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Wednesday, March 12, 2014 1:39 AM
To: Maruyama, Shinya
Cc: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: Re: [EME] Persistent license


Yes, the note regarding session id uniqueness was intended to explain that if the UA supports retrieval of sessions by SessionId (now using loadSession) then it will need to ensure that the session ids have the necessary scope.

We should consider making this normative, since as you say loadSession is not very useful otherwise.

... Mark

Sent from my iPhone

On Mar 11, 2014, at 8:36 AM, "Maruyama, Shinya" <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote:
Hi all,

I'm concerned about 'persistent' attribute usage mentioned in Bugzilla#24025.


The attribute seems to be very useful to switch at runtime whether to store acquired license by createSession or load stored license by loadSession. I prefer this option rather than CDM deciding it implicitly as current methods assume. (There should be the case where application wants to avoid storing the license no matter whether the license/drm permits to store it. 'persistent' attribute seems to be reasonable to introduce for the reason).

In addition to these usages, I wonder if we could use the attribute to determine whether to load stored license in createSession. That is, persistent=true enables createSession to behave like offline first as application cache. Meaning, createSession with persistent=true tries to use cached license first. If there is no available license then it tries to acquire the license from server.

In the use-case of loading persistent license, I think the usage of createSession above is better than existing loadSession because of a interoperability problem for loadSession(sessionId). The rules of sessionId generation does not ensure that sessionId is unique across the browsing context. It may cause sessionId collision between current sessionId and a sessionId stored in CDM, which may result in unexpected overriding of sessionId or loading wrong license due to unexpected overriding etc. Unless EME clearly specifies that UA supporting loadSession must take care of such a collision, loadSession may behave in browser dependent way (The description in 1.1.4 "Note: Some use cases may require that Session IDs be unique within the origin over time, including across browsing sessions." may imply the rule but currently this is just a informative).

Shinya Maruyama
Received on Wednesday, 12 March 2014 00:47:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:02 UTC