[Bug 24082] Several issues discussed in the TF point to the need for defined extensibility points in EME

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082

--- Comment #10 from Joe Steele <steele@adobe.com> ---
Most of the issues I raised here have been dealt with elsewhere. 

(In reply to Joe Steele from comment #8)
> Where are we on this? The thread has gotten very long and hard to follow. 
> Hopefully the new Use Cases wiki [1] will narrow down these discussions. :-)
> 
> I would like to see the following extensions to the spec (restating comment
> 1):
> 
> * Support for domain join and leave
> I think this one can be dealt with later if we don't want to tackle that use
> case yet.

Another bug was filed for this (bug 25217) and closed as RESOLVE LATER.
> 
> * Support for server communications not directly tied to a media session
> This is to support cases where it would be advantageous to acquire keys
> before the user has actually selected the content to play. This can be
> supported today by passing in initData that is acquired from some source
> other than the media file. E.g. a "standard key package" initData provided
> to authenticated users of a service. I don't see a problem here unless
> someone objects to this mechanism. 

This turned out to be a non-issue. The application can and should create a
media session for this use case. That works for me. 

> * Support for application data 
> It would be very helpful to be able to add custom data from the application
> that could then be signed by the CDM as part of the key request. 

This is still an issue. It can (and will if not if addressed in the spec) be
implemented by applications via modifying the initData passed to the CDM to
contain the additional information desired or by browsers supporting
non-standard additional parameters to the createSession/generateRequest
methods. Neither of these seems to add to interoperability. 

(In reply to David Dorwin from comment #9)
> EME should not endorse vendor-specific extensions. See also
> https://github.com/w3ctag/spec-reviews/blob/master/2014/10/eme.md#author-
> facing-interoperability-between-key-systems.

I will not go into detail here about the issues I have with this review. There
are some interesting discussions going on in the restricted-media mailing list.
For example -
http://lists.w3.org/Archives/Public/public-restrictedmedia/2014Feb/0002.html

> 
> In addition to interoperability, such unvetted extensions may also
> compromise the security and privacy properties of the spec. Likewise,
> supporting such extensions would make it difficult to reason about such
> properties.

This is veering into the secure origin discussion in bug 26332. The channel
between the application and the CDM already exists. Adding additional data from
the same source to the channel does not change the security calculus. We are
just talking about the semantics of how it gets added, not whether it can be
added at all. 

> I believe we have sufficient points to extend the standardized feature set
> in the future if necessary. For example, SessionType and
> MediaKeySystemOptions.

I think we are getting closer. But this issue still exists. It can be worked
around as I mentioned above, but I don't think that what I described is the
right solution. The right solution is to either eliminate the need for this
extension or have explicit support for it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 16 October 2014 18:21:40 UTC