Re: [EME] Persistent license

On Fri, Apr 4, 2014 at 9:25 AM, Joe Steele <steele@adobe.com> wrote:

> Replies inline —
>
> On Apr 4, 2014, at 1:21 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com>
> wrote:
>
> I think we need to address the disagreement for the way of loading
> persisted license.
> The following is the downsides of loadSession I have come up with.
> Your opinion?
>
> *1) No sufficient sessionId generation rule*
> Currently solo UA is allowed to generate a sessionId. It leads to
> sessionId collision which causes unspecified behavior; e.g. overriding,
> error, etc, because persisted sessionId is known to only CDM. Even if we go
> for loadSession, we need to add an explicit rule to avoid sessionId
> collision.
>
>
> The text covering the session ID (
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#session-id)
> specifies that it must be unique per browsing context and can be generated
> by the CDM. So at least for your CDM you can control this. I don’t see an
> issue here.
>
>
> *2) Performance penalty*
> Even if we have a fixed rule of #1 above, it requires CDM to look through
> all the persisted sessionId each time createSession is called
>
>
> I agree.
>

I don't understand. How does loadSession() impact createSession() in this
way? If anything, using loadSession() to load persisted sessions avoids
performance penalties that may occur if createSession() is allowed to load
persisted sessions.

>
>
> *3) SessionId is losable reference to persisted license*
> As an application need to persist a sessionId BEFORE or AFTER the
> sessionId is persisted in CDM (most probably update() context). In case of
> AFTER (I think this sequence is typical), it possibly causes sessionId
> being lost to application due to, for example, failing to store sessionId
> in localStorage. Then, application can no longer remove the persisted
> license.
>
>
> I agree, but I am not sure this is problem the spec can correct for. The
> application can always fail to store information which later turns out to
> be needed. I don’t think we can solve for this in a general way.
>
>
> *4) Optional loadSession is dependent on user agent implementation*
> If loadSession is not supported in a user agent, we can’t support
> persisted license in the user agent even though CDM supports it.
> If we allow createSession (or new mandatory explicit method) to load
> persisted license, whether to support persisting license is up to CDM
> implementation.
>
> User agents are ultimately responsible for what is exposed to the web
platform and ensuring
security<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#security>and
privacy<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#privacy>.
They are also responsible for vetting the key systems (CDMs) they expose
and deciding what features to expose. Whether loadSession() is mandatory or
not does not affect this.

Nothing actually says loadSession() is optional. The method must exist.
However, a user agent could choose to only execute step 1.

>
> I agree. I don’t see the benefit loadSession provides over createSession.
>

Applications will see a consistent and expected behavior. They will know
when data is being loaded and when a new session is being created. This
goes hand in hand with being explicit about when data is persisted. If this
is not explicit, applications won't know when they need to clear it. There
is a real world issue right now with some implementations that is directly
related to this issue. Also, separating the methods avoids potential
performance issues in the non-persisted case.

>
>
> Shinya
>
> *From:* Joe Steele [mailto:steele@adobe.com <steele@adobe.com>]
> *Sent:* Tuesday, April 01, 2014 5:28 AM
> *To:* Maruyama, Shinya; David Dorwin; Mark Watson
> *Cc:* public-html-media@w3.org
> *Subject:* Re: [EME] Persistent license
>
> Hi Shinya,
>
> Replies inline —
>
> Joe
>
> On Mar 19, 2014, at 7:30 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com>
> wrote:
>
>
>  Joe, I agree on those three models.
> As for the API, I’ve come up with something I want to share with you.
>
> * store license : createSession() vs. persist()/store()
> Adding a parameter (enum?) to createSession enables update() method to
> store the license. It means we add a new step like “cdm stores license if
> license permits persisting” before step 3-3-2 of update() method;
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-update.
> Because this additional step is run before resuming playback, it may cause
> performance penalty.
> As for new persist()/store() method, it does not pay such a performance
> penalty. However, if a cdm does not support storing license, the timing of
> when application receives the error is delayed after license is acquired
> whereas createSession with additional parameter can return the error before
> firing message event.
>
> This is a good point. Providing an error up front when the session is
> created would be useful to avoid later errors.
>
>
>
> * load license : createSession vs. loadSession
> createSession with an enum(?) parameter enables UA/CDM to implement
> comprehensive models. I still could not understand the reason why loading
> license in createSession is problem
>
> This does not make sense to me either. I think we can load existing keys
> in createSession as needed.
>
>
> loadSession with using sessionId looks problematic for me; e.g. if
> sessionId stored in application is lost - for instance, after cdm store the
> license and before storing it in local storage etc - application can no
> longer remove the license stored in cdm. It possibly leads to sessionId
> leak and then eventually runs out of numerical sessionId.
> I think it would be better that the license stored in CDM can be removed
> as long as application has the associated content. createSession(type,
> initData) makes it possible whenever license is loaded and then released by
> the content.
> Maybe I missed some reason why createSession should not load the license
> but I do not think current loadSession is good enough as a solo solution
> for the use of persistent license.
>
> I would prefer we use something like the key ID to load/store/remove
> licenses. Session is not specific enough.
>
>
>
> Probably we need to take into account the case license is stored by
> application on behalf of CDM (maybe whether to support this should be
> discussed separately though). Actually UltraViolet support this use case by
> introducing DMP. Given this case, adding granular methods for each case
> might be better for license store; e.g. store() for CDM level persisting,
> unload() for app level.
> For loading license, additional method loadLicense(license) might better.
> This method is called upon createSession(type, initData,
> mode=USE_APP_LICENSE) which neither loads cached license nor firing message
> event. USE_APP_LICENSE expects license(s) to be loaded by the laodLicense.
>
>
> I agree with allowing the application to manages licenses to the extent
> possible. However — there is currently no mechanism for the CDM to provide
> a license appropriate for storing by the application. The key server
> response which contains licenses may contain other things as well. Since
> there is no way for the application to be aware of this in a  general way,
> the application will have to have key-system specific code to handle this
> case.
>
> If we provide a mechanism which allows the application to:
> a) query if a license exists by key id and return the license as an opaque
> blob
> b) load a license by key id
> c) remove that license by key id
>
> This would allow us to do all the things required for Ultraviolet and
> would also allow applications requiring authenticated key release to manage
> their keys directly.
>
>
>
> Thanks,
> Shinya
>
> *From:* Joe Steele [mailto:steele@adobe.com <steele@adobe.com>]
> *Sent:* Tuesday, March 18, 2014 3:44 AM
> *To:* David Dorwin
> *Cc:* Maruyama, Shinya; Mark Watson; public-html-media@w3.org
> *Subject:* Re: [EME] Persistent license
>
> Just to give a specific usage model — in our applications today we have
> three modes for license persistence:
>
> 1) Use if available - if a cached license is available, use it. Otherwise
> try to request one.
> 2) Force Offline - if a cached license is available, use it. Otherwise
> FAIL.
> 3) Force Online - Ignore any cached licenses. Request a fresh license from
> the server.
>
> We have not run into any use cases this does not cover. I would suggest
> that is a good model for the enum to follow.
>
> As far as the application loading stored sessions explicitly — I still
> have a problem with that. Since the application has no visibility into what
> licenses actually came back in the license server responses, it will have
> not choice but to load all the stored sessions it has ever seen. This seems
> quite heavy weight to me. Maybe I am missing something about the
> notification mechanism?
>
> Joe
>
> On Mar 17, 2014, at 10:27 AM, David Dorwin <ddorwin@google.com> wrote:
>
>
>
>  tl;dr: Ignore the existing proposal for a “persistent” attribute. I’ll
> provide an updated proposal this week. Also, createSession() should not be
> loading persisted licenses.
>
>
> Joe makes a good point that the license would specify whether the CDM is
> allowed to such a license.
>
> After thinking about this more, I do not think an attribute or the
> proposal for it are the right way to handle this. Persistence is really a
> property of the license request and thus should be passed to
> createSession(). I’ll update the bug with a new proposal. More details
> below.
>
>
> The original intent of such a value was to indicate to the CDM that it
> should create license request(s) for a persistent license (if there are any
> applicable differences). This was lost in the “persistent” attribute rough
> proposal, which incorrectly focused on license storage.
>
> In either case, the state (i.e. license) was to be stored by session ID as
> the result of the update() call. loadSession() would load the state
> associated with the session ID.
>
>
> The proposed “persistent” attribute would have applied to the entire
> MediaKeys object, but it is really only used in generating license requests
> when handling createSession() calls. In addition, loadSession() probably
> isn’t useful without unless persistent=true. Thus, it seems that the
> intended behavior would be better addressed by an optional parameter to
> createSession(). This would also allow throwing a NOT_SUPPORTED_ERR if
> persistent licenses (and requests for them) are not supported.
>
>
> One remaining question is whether the CDM should implicitly store a
> license that allows itself to be persisted while handling the update()
> call. If the server did not grant a persistable license, it is possible
> that the CDM will not store a license that the application expected to be
> stored. This would likely be an application problem, but it is still
> unexpected. Do we need an explicit store()/persist() method on
> MediaKeySession? This would, of course, only succeed when the license
> allows.
>
> There might also be a use case where a special license request is needed
> but the application will store the license (and thus loadSession() is not
> used). With a single Boolean, there is no way to differentiate the two use
> cases. This could be solved using an enum instead of a Boolean for the
> extra parameter. This could also be solved by requiring an explicit
> persist()/store() call as mentioned above. (Regardless of this use case, I
> propose that the new createSession() parameter be an enum named
> licenseType.)
>
>
> Returning to the original topic of this thread, persisting sessions
> requires more application logic than the simpler “streaming” use case. Such
> an application likely wants to know what it has persisted, so storing the
> related session IDs with that information seems reasonable.
>
> There was no intent to be able to load stored sessions using
> createSession(). There has been discussion of allowing implementations to
> not fire a “message” event when the CDM already has a license for the
> initData - as a way of dealing with the numerous “needkey” events that may
> occur for the same key(s) - but this was always in the context of normal
> streaming licenses. I don’t think this should be a method of loading
> stored/persisted licenses. There are a variety of performance,
> interoperability, algorithmic, and design reasons not to do so.
>
> David
>
>
> On Mon, 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 <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
>
>
>