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