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