Re: [EME] key share policy

I believe for #6 you meant "key persisted in App across origins”. That would follow the pattern of the earlier items. 

I think all the descriptions below are correct. 

I would add to #6 that this does not introduce any additional privacy concerns, since the app will be subject to the cross origin policy the UA is enforcing. This is effectively no different than if the app were to hand the key responses directly to another origin. I can see this being useful for content providers that have multiple video sharing apps which share users.

Joe

On Apr 4, 2014, at 2:53 AM, Maruyama, Shinya <Shinya.Maruyama@jp.sony.com> wrote:

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