Re: Clarifying key types and persistence

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