- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Mon, 6 Oct 2014 12:28:39 +0300
- To: David Dorwin <ddorwin@google.com>
- Cc: Joe Steele <steele@adobe.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>
On Wed, Apr 2, 2014 at 11:01 PM, David Dorwin <ddorwin@google.com> wrote: > Thanks for summarizing the types. Comments inline. > > On Tue, Apr 1, 2014 at 2:34 PM, Joe Steele <steele@adobe.com> wrote: ... >> App and device keys: Keys that are bound to a particular device and/or >> application. > > > Are you referring to individualization or provisioned keys? This hasn't been > discussed, but I think such keys should be the responsibility of the user > agent and outside the EME APIs (assuming it is per device and there are > still appropriate safeguards and notifications). I think it's a valid design decision for a CDM to treat individualization to happen out of the scope of EME. However, I think it's wrong for the EME spec to require individualization to happen out of the scope of EME or even tacitly assume that that's always the case. I think the spec should also cater (in the sense of catering to the persistence implications) to the case where individualization happens via the EME API. Here are two completely reasonable examples of possibilities of individualizing via EME: The common part: The Key System has a "individualization needed" message. When the CDM needs to be individualized, it emits this message and expects to receive an individualization blackbox (IBX) as a response EME message. Two options for the next step: Option 1: The above-mentioned message gets relayed to the Key Server like any other EME message without the JS app treating it differently from other EME messages. The Key Server recognizes the requests as an IBX request and proxies the request to an individualization server and forwards the response IBX to the JS program, which pushes the IBX to the CDM as an EME message. Option 2: The above-mentioned message is routed to an individualization server by the JS app either by looking inside the message ArrayBuffer (worse fit for the design of EME), or if https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-mediakeymessagetype is extended to flag the message type as "individualizationrequest", by the event type (better fit for the design of EME). The JS app pushes the response IBX to the CDM via EME. The individualization server, of course, needs to permit the request using CORS and needs to support https to avoid mixed-content blocking if the EME-using site is using https. I think it would be worthwhile to have an informative note in the spec saying that individualization is a common pattern in DRMs and that it can be done as described above or it can be done outside the scope of EME. (I.e. the CDM having a non-EME mechanism for contacting an individualization server.) I also think it would be worthwhile to extend the MediaKeyMessageType enum to be able to flag messages as IBX requests for the benefit of "Option 2" above. -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Monday, 6 October 2014 09:29:06 UTC