Individualization

[Subject changed  from "Clarifying key types and persistence"]

On Mon, Oct 6, 2014 at 2:28 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

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

I assume you are referring to *per-origin* individualization, which Joe has
previously mentioned.

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

At least Option 1 must be supported because applications should not be
required to handle message types.

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

Do you really mean IBX? The Microsoft documentation [1] says that IBX is
*software*. It seems like a really bad idea to accept executable code to
become part of the user agent from a web application.

Does your case involve executable code or something simpler like an ID or
certificate?

[1] http://msdn.microsoft.com/en-us/library/cc838192(VS.95).aspx

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

The per-origin identifiers that presumably come with per-origin
individualization are good for privacy. However, it's unclear whether
deferring such individualization to a centralized server maintains those
qualities. (I am assuming the reason for the proxying is that the
"individualization server" is not run by the application provider.) This
also requires every content provider to understand the privacy implications
of doing so (for every client implementation), which is unlikely to be the
case. (With user agent-driven initialization, only the user agent vendor
needs to understand the implications of this on each particular client it
supports.)

Is use of a centralized server necessary? Maybe there is another way to
achieve per-origin IDs without contacting a central server for each origin.

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

The CDM definition
<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#cdm>
now
has some information about individualization, including the
origin-independent outside-the-APIs pattern.

It briefly mentions per-origin initialization, and we can consider
expanding it. We should also keep in mind that it would be better if there
aren't multiple ways to do things depending on the key system and/or client.

>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/
>