Re: [EME] Persistent license

I replied inline below to various branches of this thread.


On Fri, Apr 4, 2014 at 3:26 PM, Joe Steele <steele@adobe.com> wrote:

> On Apr 4, 2014, at 1:26 PM, David Dorwin <ddorwin@google.com> wrote:
>
>  *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.
>
>
> Can you explain why this implementation issue would be satisfied by a
> loadSession() call but would not be equally satisfied by a loadKey call?
>

I was comparing it to using createSession(), not loadKey().


> Also — can you explain what the performance issue is that you see in the
> non-persisted case?
>

If createSession() *may* load sessions, ever createSession() call - even
those for non-persisted use cases - would need to search the persisted
sessions for one that contains an initData match. With loadSession(),
createSession() doesn't need to look at persistent storage at all, and
loadSession() can look up sessions by sessionId, which is smaller and more
straightforward than variable-sized initData.

>
> The only issue I see that could potentially require a loadSession call is
> the need to explicitly use persisted keys as opposed to allowing the CDM to
> request them from a server. Shinya mentioned this on another thread and we
> have seen this customer requirement as well. But I have only seen this as a
> firm need in the offline playback case which the group has basically said
> we will not support yet.
>
> This is the use case that loadSession() and the |licenseType| parameter
seek to address. These simple additions add support for acquiring and
retrieving offline licenses in an explicit and consistent way. This is
currently why persistence is allowed.


On Sun, Apr 6, 2014 at 7:31 PM, Maruyama, Shinya <
Shinya.Maruyama@jp.sony.com> wrote:

> [sm] I understand CDM is allowed to generate sessionId but spec is not
> clear enough for the condition that -  when UA supports loadSession,
> sessionId generation (in createSession) must ensure that a new sessionId is
> unique within not only all the active sessionIds but also all the persisted
> sessionId.
>
> Therefore, EME should specify the clear requirement for sessionId
> generation, which is only applied to UAs supporting loadSession; e.g.
>
> - Add a normative description like “session ID must be unique across
> browsing context
>
> - Add in createSession algorithm a step of retrieving persisted sessionId
> and checking them for the uniqueness across browsing context
>
>
>
Adding such a step would negatively impact performance. See above. Also, I
don't think we need to specify *how* a CDM ensures uniqueness. There are a
variety other options.


On Sun, Apr 6, 2014 at 7:35 PM, Maruyama, Shinya <
Shinya.Maruyama@jp.sony.com> wrote:
>
> [sm] As mentioned above, currently whether to be able to support
> loadSession is dependent on sessionId generation algorithm of
> createSession. Thus, CDM implementers can’t implement loadSession without
> making sure what sessionId generation algorithm is implemented in a user
> agent.
>

>From the spec: The sessionId "may be obtained from cdm." Any user agent
looking to support such functionality is likely to rely on the CDM to
generate session IDs.