Re: [EME] Persistent license

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