RE: [EME] key share policy

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.

From: Maruyama, Shinya [mailto:Shinya.Maruyama@jp.sony.com]
Sent: Friday, April 04, 2014 6:54 PM
To: 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"
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."

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
- the pssh is in conformance with common encryption second edition. Meaning all necessary KIDs are contained in pssh.
- 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
  -- state transitions must be affected to other sibling sessions
  - 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.

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?