Re: Clarifying key types and persistence

On Fri, Apr 4, 2014 at 3:52 PM, Joe Steele <steele@adobe.com> wrote:

> I tried to point out several reasons why keys delivered often belong to a
> hierarchy of keys. It basically boils down to performance or business
> reasons. There is content available today and more coming online which
> relies on a hierarchy of keys being available.
>

If EME does not address the underlying requirements in an explicit and
standard way, such content may remain inaccessible to many clients and
users.

>
> I don’t see how the model you are pointing to precludes what I am
> describing. The question seems to boil down to - what keys does the
> application have to deal with? I believe the application has to deal with
> two types of keys - content keys and domain keys. Both of those can require
> action by the application. None of the other key types require action by
> the application.
>

I believe that if domain keys are to be supported, EME should explicitly
address them rather than simply allowing them to fit. You said in your
other email that domains can work across key systems - that's great, but
for clients to be truly interoperable, I think EME needs to be more
explicit about the behavior such applications should expect. Domain keys
also present additional issues, including as cross-origin, privacy, and
persistence, that we should explicitly consider.

>
> BUT — we should not design the APIs in such a way that those other types
> of keys cannot be used. Several recent proposals seem to be tightening key
> usage to the point where they will exclude participation by content
> providers with business models that require them. Even if we decide that we
> don’t want to support some of this functionality right now, I don’t want to
> see the spec defined in such a way that would make it difficult to add
> support in the future without killing backwards compatibility.
>

See above. Real world implementation experience has shown that the spec is
too ambiguous and/or implementations have been too liberal for
interoperable applications to be written, even when only using content
keys. I want to fix this. That doesn't mean other models can't be
supported, but I don't think underspecification or ambiguity is the right
answer. HTML5 doesn't specify which containers or codecs may be used, but
it is very specific about the user agent's behavior and what should be
presented to the application when to present it.

>
> Joe
>
>

On Fri, Apr 4, 2014 at 5:36 PM, Joe Steele <steele@adobe.com> wrote:

> I missed commenting on the other bits in my earlier email —  more comments
> inline:
>
> Joe
>
> On Apr 4, 2014, at 3:52 PM, Joe Steele <steele@adobe.com> wrote:
>
> On Apr 4, 2014, at 9:49 AM, David Dorwin <ddorwin@google.com> wrote:
>
> <snip>

>   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.
>>
>>
>> Many browser players today use the key types described above for
>> decrypting content.
>>
>
> Can you provide examples? Are you referring to players built in Flash?
>
>
> Mainly Flash and Silverlight players. I believe there is a Marlin plugin
> as well which would support this key model, but I do not have personal
> experience with it. I believe the FairPlay support available via Safari
> (out of scope for this spec - I know) also supports key chaining. Without
> talking about specific customers implementations I don’t think I can share
> any more details, but that should be sufficient.
>

The needs (interoperability, cross platform, security, privacy, etc.) and
application model of the open web platform may be very different from players
built in such proprietary frameworks.

<snip>

>
> Domain keys allow a further level of abstraction from the license server.
> For example a collection of cooperating content providers can all share a
> service for managing domain membership. The user benefits by having one
> place to go to manage the set of devices for multiple service providers.
> The businesses benefit by not having to each maintain a device management
> service.
>

There are other solutions for this. Websites commonly rely on other
providers for services. Why can't the same techniques be used here?

>
> Another user-facing use case is the ability to side-load licenses. Using
> domains, you can acquire licenses which will play on any player in the
> domain and then transfer those licenses between players as needed. This
> enables people who want to be able to backup their licenses in case a
> device goes dead.
>

I don't understand this use case. More work is probably necessary to
determine whether and how to support it in the web platform. (How are
licenses retrieved and transferred, etc.?)

>
>
> Can this work across key systems? Does it still make sense in that case?
>
>
> Are you asking whether two key systems can both use domain keys for the
> same content? The answer is yes. The license servers will know based on the
> type of request they get which key system is being used and therefore which
> domain key to use. This workflow is currently used for Ultraviolet players
> for example based on Flash or Silverlight.
>

That's good news. So, what would an interoperable domain-using web
application that supports Adobe Access and PlayReady (for example) look
like?

>
>
>> *2) Streaming content bundled into libraries*
>>
>> In this use case the user is able to select content organized in
>> libraries (e.g. by studio). Each library is encrypted with content keys
>> which are bound to a common library root key.
>>
>> This can be done for many reasons, but here are a few common ones:
>> * the content provider needs to be able to disable a library of content
>> for everyone (usually for contractual reasons)
>> * the content provider needs to be able to disable individual library
>> access for a user (usually because of service changes)
>> * the player gets a significant performance boost from not having to
>> acquire licenses for each new piece of content once the library is acquired
>>
>
> Does this assume that the content key is delivered (encrypted with the
> library key) with media data? Is it embedded in the media data or media
> resource?
>
>
> The content key could be embedded in the content (e.g. in the PSSH) or
> provided as a separate HTTP download. The goal is to avoid hitting a
> license server, not necessarily to avoid any network traffic. Obviously in
> the streaming case we are still downloading the content itself.
>

I'm not aware of any content format under discussion that specifies
embedded keys. Including the key in the PSSH would be problematic since
that wouldn't really be **common** encryption. Even providing it in a
separate HTTP download is problematic because there is no specified way to
interpret or provide such data to the CDM.

How might EME explicitly support such a model?

>
>
> Is the same true for (0) and (1)?
>
>
>
> (0) is completely independent of (1) or (2). In the domain case, the
> content key is delivered the same way as a normal player-bound key is
> delivered. But instead of the keys being tied directly to that player they
> are tied to a key shared by several players.
>
>
>