Re: [EME] Persistent license

I agree — there are aspects of license policy that are not primarily enforced by the DRM.

I was trying to point out that license persistence is actually an aspect that is primarily enforced by the DRM, not by the application. The application can say “don’t cache this license” but the application can’t say “cache this license” without some additional compliance from the CDM. I think we are basically saying the same thing here. 

Joe

On Mar 17, 2014, at 1:52 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com> wrote:

> Hi Joe,
>  
> I think we can’t have an assumption that the 'license policy' can be available to CDM only through DRM license because retailer/ecosystem may requires some complemental limitations or obligations which the system (rather than solo DRM client) must comply with.
>  
> In general, DRM license describes fundamental usage rules which DRM client must comply with; e.g.
> - user-bound or device-bound
> - validity period
> etc
> while retailer or ecosystem may require non-DRM limitations or obligations along with the license; e.g.
> examples for UltraViolet
>  - The maximum number of Devices concurrently joined to a Domain
> - The maximum number of concurrent LASP Sessions
> etc
>  
> In case of caching license, the DRM license must have the permission for 'persist' but it is not sufficient. In addition, the distributing retailer or ecosystem should also allow to persist it.
> For instance, retailer may expect receiving license acquisition for every streaming to count the number of licenses issued concurrently or to check whether or not requesting client is revoked, etc. This may be accomplished by license acquisition (may be accomplished in out-of-band way though).
>  
> My proposal is to add normative way substitute for existing loadSession to switch whether to store or load the license at runtime. Therefore, your proposal“ignore_cached_licenses” is also fine with me (although the name looks confusing because the flag also should have an affect on whether to store the license for the ‘privacy mode’).
>  
> Thanks,
> Shinya
>  
> From: Joe Steele [mailto:steele@adobe.com] 
> Sent: Thursday, March 13, 2014 2:58 AM
> To: Maruyama, Shinya
> Cc: Mark Watson; public-html-media@w3.org
> Subject: Re: [EME] Persistent license
>  
> I don’t think it is useful for the application to determine the persistence of session information. 
>  
> Assume an application wants to set this attribute to “false”:
> The consequence for some CDMs would be a significant performance penalty. Most CDMs require an “individualization” step where device-specific keys are acquired. For some CDMs this step is costly in terms of battery cost, processor time, additional network transactions. So applications that want reasonable performance will have to figure out which key systems have this cost and always set this flag “true” in those cases anyway.  
>  
> Assume an application wants to set this attribute to “true”:
> The retailer sets a license policy that determines whether licenses can be cached and for how long. So even if the application says to cache the licenses the CDM will ignore this in favor of the license policy. Since the application is generally controlled by the retailer that is setting the license policy, and setting the license policy will have a more comprehensive effect than setting the application attribute, the retailer has no incentive to set the application attribute and will instead set the license policy at the time the license is issued.
>  
> If the goal of this attribute is to protect user privacy, the user would be better served by running the application in “privacy mode” where no transaction results are cached by the browser. 
>  
> If the goal of this attribute is to protect retailer assets, the retailer would be better served by applying an appropriate license policy and selecting a key system that enforces it properly. 
>  
> I think your specific concern would be better resolved by a more specific attribute like “ignore_cached_licenses”. This would direct the CDM to ignore any cached licenses (excluding “individualized” keys mentioned above) and allow the application to acquire a fresh set of licenses. I would support that attribute. 
>  
> Joe
>  
> On Mar 11, 2014, at 5:46 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com> wrote:
> 
> 
> 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.
>  
> Thanks
>  
> 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.
>  
> ...Mark
>  
> 
> On Tue, Mar 11, 2014 at 4:21 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com> wrote:
> Mark,
>  
> 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.
>  
> Thanks,
> Shinya
>  
> From: Mark Watson [mailto:watsonm@netflix.com] 
> Sent: Wednesday, March 12, 2014 1:39 AM
> To: Maruyama, Shinya
> Cc: public-html-media@w3.org
> Subject: Re: [EME] Persistent license
>  
> Shinya,
>  
> 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> wrote:
> 
> Hi all,
>  
> I’m concerned about ‘persistent’ attribute usage mentioned in Bugzilla#24025.
>  
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c10
>  
> 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).
>  
> Thanks,
> Shinya Maruyama