Re: [EME] Persistent license

This makes sense. 

In the “ask for persistence” case David pointed out, the license server may allow both models but track the licenses issued differently.

There is also the “ask for non-persistence” case. In this case the CDM can avoid caching keys even when that would be allowed by the DRM policy, for example on a public computer. This is what I was thinking of. 

Joe

On Mar 31, 2014, at 1:38 PM, David Dorwin <ddorwin@google.com> wrote:

> Think about an offline scenario. The application wants to save streams and a license for later viewing offline. Only the application knows what it (and the user) intends to do. The proposal allows the application to request a persistable/persisted license. The license server can then validate whether this is allowed and reply with the requested license. Without this information, the license server doesn't know whether to provide a streaming or persistable license. The application and user might have both capabilities.
> 
> David
> 
> 
> On Sat, Mar 29, 2014 at 5:57 AM, Mark Watson <watsonm@netflix.com> wrote:
> IIUC the rationale for the new parameter is that there may be cases where the license server does not impose a persistence choice (to persist or not to persist) on the DRM and so the application is given the choice. 
> 
> Can someone give an example use-case where this would be the case ? I'm unsure how it could be that the license server doesn't know whether the license should be persisted or not.
> 
> ...Mark
> 
> Sent from my iPhone
> 
> On Mar 29, 2014, at 1:27 AM, David Dorwin <ddorwin@google.com> wrote:
> 
>> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25200 with my updated proposal.
>> 
>> David
>> 
>> 
>> On Tue, Mar 25, 2014 at 11:58 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com> wrote:
>> Of course…if tamper-resistant DRM is obligated not to store the license then CDM/DRM must reject to store the license in persist()/store() call.
>> 
>>  
>> 
>> From: Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com] 
>> Sent: Wednesday, March 26, 2014 3:53 PM
>> To: Jer Noble; Joe Steele
>> Cc: Mark Watson; public-html-media@w3.org
>> Subject: RE: [EME] Persistent license
>> 
>>  
>> 
>> Probably I have to clarify the cases I have envisioned. I hope the following would make sense to you.
>> 
>>  
>> 
>> If tamper-resistant DRM (part of CDM) is obligated to store the license (as a result of communication with server), the DRM/CDM stores the license within update().
>> 
>> If tamper-resistant DRM is permitted to store the license, we can leave the choice of “whether to persist” to an application that is not protected against tampering. Depending on platform/service on/for which an application runs, the application may change the behavior; e.g. app on PC stores the license but app on TV/STB discards the license.
>> 
>> My concern is current EME can’t cover the latter case. I think new persist()/store() method can cover this case.
>> 
>>  
>> 
>> Thanks,
>> 
>> Shinya
>> 
>>  
>> 
>> From: Jer Noble [mailto:jer.noble@apple.com] 
>> Sent: Wednesday, March 19, 2014 3:22 AM
>> To: Joe Steele
>> Cc: Maruyama, Shinya; Mark Watson; public-html-media@w3.org
>> Subject: Re: [EME] Persistent license
>> 
>>  
>> 
>> I think that what Joe is saying–and it is true in any case–is that typically the DRM is protected against tampering and the application is not. So offering an app API that modifies the use restrictions–e.g. to either opt in or opt out of using a cached license–is a bad design because it will simply be abused by an attacker in whichever way provides the most advantage. 
>> 
>> 
>> If “retail” wishes to modify the default behavior of the DRM then it must do so server-side, where the code is trusted, and communicate it to the client through the tamper-resistant DRM protocol.
>> 
>>  
>> 
>> -Jer
>> 
>>  
>> 
>> On Mar 17, 2014, at 11:38 AM, Joe Steele <steele@adobe.com> wrote:
>> 
>>  
>> 
>> 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
>> 
>>  
>> 
>>  
>> 
>> 
>