- From: Mark Watson <watsonm@netflix.com>
- Date: Sat, 29 Mar 2014 12:57:25 +0000
- To: David Dorwin <ddorwin@google.com>
- Cc: "Maruyama, Shinya" <Shinya.Maruyama@jp.sony.com>, Jer Noble <jer.noble@apple.com>, Joe Steele <steele@adobe.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <5791563329520717613@unknownmsgid>
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 > > > > >
Received on Saturday, 29 March 2014 12:58:00 UTC