Re: Clarifying key types and persistence

Thanks for summarizing the types. Comments inline.

On Tue, Apr 1, 2014 at 2:34 PM, Joe Steele <steele@adobe.com> wrote:

> In the call today it became clear there still seems to be disagreement
> over what types of keys should be supported by the Encrypted Media
> specification.
>
> We have had lots of discussion on sharing keys between domains and app
> instances:
> http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0022.html
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202
>
> We have had lots of discussion on storing keys persistently:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19785
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
>
> These are the types of keys I see in common use:
>   Key system keys:  Keys that are common across many instances of the key
> system, not bound to a particular application or device.
>

Can you provide more details? Is this something like a global key for all
implementations of the DRM? Do applications need to be aware of this?

  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'm not sure what an "app" key is or how that fits in the web platform. I
would not apply the same logic to such keys at this time.

   License chaining keys:  Keys which are used to derive or unwrap content
> keys. One example would be  domain keys as used by Ultraviolet.
>

This seems to be the primary unaddressed issue, but I don't think there has
been a comprehensive presentation or discussion of the use cases. It's
unclear whether and how these should work in the web platform.

   Content keys:  Keys used to directly encrypt content.
>

These are the keys that the EME APIs have been designed around since the
first draft. All key systems and common encryption media streams use them.
Each Key is associated with a key ID and lives in a single MediaKeySession.
initData identifies (possibly indirectly) the key ID(s) that should be in
the resulting license.

>
> There seems to be disagreement in the group about which of these key types
> should be supported. Some of these keys are required for the underlying key
> systems to function at all. Some of these keys enable business models. Some
> of these keys are for improving performance. All of these keys have
> legitimate uses when playing back streaming encrypted content. Supporting
> all of these key types is within the architectural model of the EME spec.
>

It's not currently clear that all of these types are consistent with the
web platform or the purpose of EME, which is to allow applications using it
to work across platforms in a consistent and expected way that is
compatible with the web platform, including its security and privacy model.

>
> The issue of key storage is linked to the issue of supporting non-content
> keys, as those keys may have a different lifetime than content keys. Key
> acquisition can be costly in various ways and minimizing the number of key
> acquisitions is generally a good thing.
>

It would be helpful to understand these issues and where/why they occur. It
would also help to better understand the types of keys above.

The goal should be to minimize the **total** time spent acquiring keys for
a given use case - whether that's one key or 10 keys is irrelevant.

>
> I propose the following changes to *Section 1.1.3 “Key Session” *to
> clarify things.
>
> *Spec text specifying that sessions refer to the in-memory representation:*
> “A Key Session, or simply Session, represents the lifetime of the
> _in-memory representation_ of any license(s)/key(s) it contains and
> associates all messages related to them.”
>

In the telecon, you said that a session might contain both content keys and
other keys. I think a session should only contain a single type of key(s).
This eliminates issues like needing to access each key individually. (How
keys in one session might use other keys is TBD pending further discussion.)

>
> *Spec text defining the relationship of keys to a Key Session: *
> “A Key Session may contain one or more keys. Keys may be identified by key
> IDs.”
>
> *Spec text acknowledging that non-content key types may be supported by
> the CDM: *
> “Keys acquired during the lifetime of a Key Session may be directly or
> indirectly used in decrypting content.”
>
> *Spec text acknowledging that keys may be cached by the CDM if allowed by
> the browser:*
> “Any keys acquired by the Key System during the lifetime of a Key Session
> may be stored as needed by the Key System and allowed by the User Agent.”
>
> This seems like a good topic to hash out a bit before we get to the F2F
> next week. I don’t think I am saying much that is new here. We have enough
> bugs filed around different aspects of this subject (17202, 17750, 25200,
> 25217, 25218, etc.) that I don’t feel the need to file another. However let
> me know if you think that is not the case.
>

As I mentioned above, I'd really like to see the web use cases documented,
not just the legacy solutions or perceived API gaps. We should evaluate use
cases and how they fit into EME and the web platform, but we should not
start from an assumption that legacy DRM systems should be exposed as-is to
JavaScript. The two key systems known to have shipped so far - Widevine and
PlayReady - have implemented new interfaces and/or wrappers to meet the
requirements of EME and the web platform. It is reasonable to expect that
other systems will need to make similar adaptations.


> Joe
>