RE: [EME] Persistent license

Replies inline.

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Tuesday, April 08, 2014 6:55 AM
To: Joe Steele
Cc: Maruyama, Shinya; Mark Watson; public-html-media@w3.org
Subject: 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<mailto:steele@adobe.com>> wrote:
On Apr 4, 2014, at 1:26 PM, David Dorwin <ddorwin@google.com<mailto: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.

As I mentioned earlier, the downside of loadSession is an user agent (and hand-in-hand CDM) supporting loadSession must ensure uniqueness of sessionId across browsing context whereas Joe’s and my proposals are independent from the uniqueness. Furthermore, for the uniqueness across browsing context, createSession always need to read persisted sessionId even in non-persisted case.
The advantage of our proposal is;
- ‘uniqueness across browsing context’ is not required
- No performance penalty on createSession due to the access to persisted assets

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.

With loadSession(), createSession() does need to look at persistent storage for sessionId generation because UA/cdm can’t generate a sessionId unique across browsing context without looking at persisted sessionId.
The advantage of our proposal, loadKey(keyId) or load(), is … it is ensured that the access to persisted assets is limited to the explicit methods which implements persisted case.


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<mailto: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.

My example was not appropriate. I agree we should not specify how to ensure uniqueness.
I just want to say current EME is not clear enough for especially user agent implementer to understand that sessionId needs to be unique across browsing context if loadSession is supported.


On Sun, Apr 6, 2014 at 7:35 PM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto: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.

I think the spec needs to be clear enough for the ambiguous requirements.


I have not had your comments on ‘3) SessionId is losable reference to persisted license’.
Do you have any idea on this? I tried to clarify more for this issue. Please see below.

Once sessionId to be persisted in app; e.g. localStorage, the app can no longer release the sessionId and license persisted in CDM whereas, for example, they can be released as long as content exists if we use initData to retrieve persisted license in CDM. I know there is the possibility of app failing to download/store content after CDM persists a license (this is a generic problem as Joe said). However, in most situation, a user would try to download the content again because that the user wants to playback the content. Then, the persisted license can be released using EME method probably when the content is explicitly removed by the user.