Re: [EME] Persistent license

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