Re: Clarifying key types and persistence

On Mon, Apr 7, 2014 at 1:48 PM, Joe Steele <steele@adobe.com> wrote:

> I would like to see these requirements specified in an explicit and
> standard as well. I have put forward several proposals which I think
> address this. I have put forward the use cases which justify their
> inclusion into the spec.
>

Which proposals are you referring to? There are so many threads right now,
and it's unclear what the proposals are.

I see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218, but it's not
clear exactly what it addresses or how.

I think https://www.w3.org/Bugs/Public/show_bug.cgi?id=25217 is only a part
of what is necessary to explicitly support domains. I don't believe we have
a complete proposal for how to support domains.

>
> Not adding explicit support for domain keys would be a mistake in my
> opinion, but obviously that is still under discussion. As I have said in
> the telco’s - players can and will work around that absence using the
> existing standard methods if forced to. I believe all of the security and
> privacy concerns around domain keys have been addressed by the privacy text
> added to the spec.
>
> I am more concerned about what I see as the removal of functionality by
> restricting what the key messages can contain. My understanding has always
> been that the content of the key messages is entirely the purview of the
> CDM and the license server. Is it your intent to define what the key
> messages can contain or am I misunderstanding? The discussion in this bug (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269) leads me to believe
> that is where you are going.
>

Bug 25269 is related to another initData format for use in createSession()
calls. It's unrelated to messages.

>
> Joe
>
> On Apr 7, 2014, at 12:48 PM, David Dorwin <ddorwin@google.com> wrote:
>
>
>
> 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.
>>
>>
>>
>
>