RE: [EME] key share policy

Please see my comments line.

From: David Dorwin [mailto:ddorwin@google.com]
Sent: Saturday, April 05, 2014 7:08 AM
To: Maruyama, Shinya
Cc: public-html-media@w3.org
Subject: Re: [EME] key share policy

Comments inline.

On Fri, Apr 4, 2014 at 5:59 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>> wrote:
Let me add one thing.

David’s proposal in bug#25092 might be good direction to solve the issue described in #1 below.
I suppose his proposal implies that we make an application aware of keyId(s) (whereas current EME is not such a model).
If this implication fit with EME or web application model, I wonder if it would also good to specify normatively key system independent field in initData where keyId(s) are listed as cenc second edition specifies. Given that in market there are already a lot of media files which are not in conformance with cenc second edition, we can’t specify this as mandatory though.
This way, application can determine whether to create media key session in standard way by checking if notified keyIds are known and corresponding session is already created.

I've been considering proposing an init data type that is just an array of key IDs. For applications that want to manage key IDs (rather than relying on the media data), this is simpler, especially compared to generating a PSSH. I filed bug 25269<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269>.

[sm] I think that is not the proposal for bug#25268<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268> but a solution to avoid manipulating pssh by app, right?

As for my original concern about redundant session creation, I understand you prefer not to implement such complicated logic in CDM.
If that is the way for us to go, we have to leave the responsibility to an application.
In that case, the problem is no standard way of how application can know what keyIds are associated with current needkey (I think proposal in bug#25269<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269> does not solve this problem).
As long as we can specify the standard way, an application can see whether or not current keyIds are already available to (or pending in) preceding session.
The best way is that container specific initData contains necessary keyIds in standard way but it’s impossible because of the compatibility with existing container format.

Given that situation, one possible workaround is just to specify ‘best practice’ for each container; e.g. As to cenc, it is recommended that pssh box contains necessary KIDs.
I understand in case of common encryption first edition, there is no standard field to contain KIDs. In that case, DRM specific field of pssh may be used for the KID container and an application is aware of it (it does not fit with the original goal of EME though).
For the comprehensive requirements, further investigation would be needed. For instance, in case of key rotation, cenc allows KIDs to be overridden by sample group description. Maybe we have to have some constraints for container usage to avoid the problem.


From: Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com<mailto:Shinya.Maruyama@jp.sony.com>]
Sent: Friday, April 04, 2014 6:54 PM
To: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: [EME] key share policy

Related to recent topics, I would like to clarify what key-share is allowed by EME.

I tried to list up the possibilities and assumed answers each by seeing past discussions in bugzilla or public-html-media.
I’d appreciate it if someone could correct the answers and add missing viewpoints if any.

1) key in-memory within an origin: “Yes”

 Currently yes, but I'd like to make it "No". See below.

This allows the transition from CREATED to READY as long as the following non-normative requirement is met; “Note: this step makes it possible for a MediaKeySession to transition from the CREATED state to the READY state. User agents might do this as an optimization but, even if this is done, all MediaKeySession instances must appear distinct regardless of the underlying implementation.”

Separate from any of the recent discussion about persistance, I believe this text should be removed (bug 25267<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25267>). It sounded good when originally discussed, but it results in inconsistent and unexpected behavior.

Applications are responsible for de-duping needkey events (if they use them). If we think that is unreasonable, we should try to solve that in the spec in a consistent way (bug 25268<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268>).

[sm] As commented above, I agree on introducing a consistent way.

If this is allowed, the following is one of the likely usecase;
- each fragmented movie contains the same pssh, which causes multiple ‘needkey’ event for the same keys each time pssh is encountered

Note that every stream switch (e.g. change in bitrate for adaptive streaming using MSE) will also result in a needkey event.

[sm] I understand it although change in bitrate does not always result in key changes. Actually DASH-IF specifies the constraint that the same keys are used within an adaptation set.
- the pssh is in conformance with common encryption second edition. Meaning all necessary KIDs are contained in pssh.

Is this a new requirement in the second edition? There is no such requirement in the first edition as far as I know. Does "all" mean all for the title, including all possible streams or just all for this stream? (The former seems problematic in practice.)

[sm] Actually this is a new requirement but I should not have mentioned the information under draft version. Sorry about that.

- CDM/createSession is capable of checking if any pending or ready key(s)/license(s) referred to by supplied pssh/KIDs is cached in memory
- If there is pending key(s), CDM transits to PENDING state and wait for the keys made available
- If there is ready key(s), CDM immediately fires ready event
- Otherwise, message event is fired
- CDM must be able to manage all the media key sessions reference to certain key(s)/license(s); e.g. manage lifetime, state-transition, event.
 -- release() must be implemented such that count of reference to the key(s) become zero

Note: Application use of release() is optional for in-memory keys.

[sm] OK. I meant if CDM supports release then …..

  -- state transitions must be affected to other sibling sessions

They are not supposed to affect other sessions ("all MediaKeySession instances must appear distinct regardless of the underlying implementation"), but it seems hard to implement in practice.

[sm] I understand the intent. (I was just not sure we could claim sessions - whose instance is distinct but references to key instance is shared  - as appearing distinct. )
  - etc

In my understanding, doing this optimization means allowing to reuse pending or cached keys between multiple MediaKeySessions (IOW, One key instance can be shared between distinct MediaKeySession instances). It means, for instance, when a key with READY state makes a transition to PENDING (e.g. for renewal), ‘message’ event is fired only once for a MediaKeySession instance. For the other MediaKeySession instances, only transition to PENDING state is happened.
I can see this kind of discussion was made in the past but no explicit solution seems to be provided yet.

If this optimization is not allowed, do you have any recommendation to avoid the problem caused by multiple needkey event?
Unless CDM implements this kind of optimization, application needs to be aware of what type of protection is made in current video playback.
For example, only first ‘needkey’ should be handled even if multiple needkey is occurred for each Initialization Segment etc.
This kind of limitation might cause interoperability problem in application layer because, for instance, each Initialization Segment may require different keys or key rotation might happen during playback etc.

Currently, the application must decide for which needkey events to create a session. Even ignoring session sharing, it doesn't make sense to allocate MediaKeySession objects potentially hundreds of times for a given playback. I'd like to find a better solution here, but I don't have any good ideas. Let's discuss in bug 25268<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268>.

[sm] I agree.

2) key in-memory across origins: “No”
Privacy reason.

3) key persisted in CDM within an origin: “Yes”
CDM persists license with origin and allows the same-origin to load persisted license

4) key persisted in App within an origin: “Yes”
This is a case license is persisted in, for example, packaged web app; e.g. UltraViolet DMP.

5) key persisted in CDM across origins: “No”
Privacy reason.

6) key persisted in CDM across origins: “Yes”?
The same for #4.
Any privacy problem?
If you mean "App" rather than "CDM", then "Yes", assuming you use the existing cross-origin capabilities of the open web platform.

[sm] Sorry for the typo. Understood.