Comments on draft opinion on EME

Dear TAG,

I read the draft opinion on EME [1] and have a few comments:

(1) It is certainly the intention that the websites, not the CDM, performs
user authentication and authorization in the usual ways websites do. If
this isn't clear, we should make that clearer in the specification

(2) Whilst the primary purpose of the Content Decryption Module is indeed
"decryption", there are a number of additional functions it has to perform
to order to be able to do the decryption.
- first, it has to receive the decryption keys. Since one objective is
often to keep these keys secret, some secure protocol is needed to do this
and this is the purpose of the opaque message exchange - mediated by the
website - between CDM and a server side peer.
- second, there is the question of "robustness" (for example, see [2]) -
which I will return to in more detail below - which often necessitates
authentication and authorization of the CDM itself (as distinct from the
user). Again, this is achieved through the opaque message exchange.
- third, compliance to the robustness rules - again, see below - often
implies restrictions on what can be done with the media subsequent to
decryption. The CDM is expected to take care of this, for example handing
off to a media pipeline that is also compliant to the robustness rules or
performing decoding and possibly rendering itself.

A "license" is exactly the information needed to provide the CDM with the
decryption keys and conditions regarding their use. Since the license
contains the decryption keys, the processing of the license needs to be
within a component subject to robustness rules and we have placed all such
functions with the CDM. Perhaps the CDM is mis-named ?

(3) There seems to be some mis-understanding in the opinion about the
relationship between CDM and CDN (for example, reference to a "secure
channel" between CDM and CDN). We don't make any assumption about how the
content is obtained, nor do we assume there is per-playback decryption key.
In particular, the content key may be fixed for a given piece of content
with the same key used for all playbacks for all users, such that the
content can be stored and served from a regular web server.

(4) There is a very substantial difference architecturally between the
MediaKeys object defined by EME and the CryptoKey object defined by
WebCrypto. At the very least it is not reasonable to say that MediaKeys is
"already defined" by WebCrypto without any analysis to back up the
assertion. MediaKeys represents a collection of communication sessions
within the scope of which licenses, containing keys and other information,
may be securely delivered to the CDM - keys are just one part of this.

(5) Regarding the three questions in the Interoperability section, it is
worth considering how the answers to these change as a result of the
introduction of EME (i.e. compared to the status quo):


   1. I am an indie studio; what should I do in order to have my content
   protected by popular DRM systems?

*Today*: You will need to choose a plugin (Silverlight, Flash, develop your
own), choose a DRM vendor (perhaps dictated by choice of plugin) develop or
buy player code for that plugin, obtain a license from the DRM vendor and
deploy license servers.
*With EME*: For coverage across all browsers, you will require licenses and
(back end) license servers for multiple DRMs, but otherwise you are
developing in HTML5, not using plugins.


   1. I am an indie browser maker; what should I do in order to make my
   browser capable of using popular CDMs?

*Today*: You need to support NPAPI plugins (with the associated security
and privacy disadvantages for your users)
*With EME*: In general, you will need to choose a DRM vendor, license their
client-side component and integrate this component with your video element
implementation. On some platforms - for example Windows - CDM functionality
may be available through platform APIs so you could simply use those APIs
to expose that functionality through your video element.


   1. I am an indie DRM vendor; what should I do in order to make browsers
   support my CDM?

*Today*: You could package your DRM into an NPAPI plugin and try to
persuade sites to use it

*With EME*: You will need to negotiate with each browser vendor to persuade
them to integrate your DRM.

Note that it is not an objective of EME to make life easier for those using
DRM, for DRM vendors or for UA implementors. The objective is to provided
continued support for DRM in the absence of plugins, with consequent
improvements to user security and privacy.

(6) Alternative

We already have open standard encrypted media formats [3]. It is the
license / key exchange that remains proprietary. I am not sure I follow how
the proposed alternative would work, but at a high level I see two
components to it:
(a) the idea of an open standard (presumably RF) for the license format and
license delivery protocol
(b) an architecture that permits implementation of this in JS using
low-level primitives such as WebCrypto CryptoKey objects, system key store
etc.

Regarding (a), such a thing would obviously be welcomed by many people but
it is my understanding that the IPR landscape in this area is such that
this is a real challenge. At least, noone that I know who is familiar with
the IPR thinks this can be done, so you would at least have trouble getting
such people to invest time in the development of such a solution. One of
the important things included with any license to DRM technology is
indemnity with respect to the IPR held by various NPEs. Not a pretty
situation, but that's the way it is.

Regarding (b), the principle challenge is robustness. One of the things the
proprietary solutions do is to provide a way for the CDM to attest to its
robustness, so that the sender of the license has some confidence as to
exactly what will be done with it - i.e. what code is going to receive it
and what robustness rules that code complies to.

Regarding the specific proposal, the CDN generally does nothing more than
serve a flat encrypted file, so I don't understand the involvement of the
CDN in the described procedure.

Best regards,

Mark Watson



[1] https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
[2] http://www.microsoft.com/playready/licensing/compliance/
[3]
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/initdata-format-registry.html