Re: [EME] key share policy

Comments inline.

On Fri, Apr 4, 2014 at 5:59 AM, Maruyama, Shinya <
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>
.


>
> *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”*
>

 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>
).

>

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

 - 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.)

>

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


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


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

>
>
> *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.