Re: Clarifying key types and persistence

I was thinking more about this last night and I may have an alternate solution for the sessions != keys problem.

You asked in one of the bugs why the application could not just manage sessions correctly. My response was that the application does not know enough about what keys are in which sessions to manage the keys effectively that way. 

It occurred to me that we could just signal to the application that a new session is required in order for key separation to be maintained. I am not sure how that would work with the new Promises API, but we could explore that. 

Here is what I imagine the workflow to look like —
1. App calls createSession with initData for the media
2. CDM responds with key request
3. App sends request and returns response to CDM via update()
4. CDM sends a “new session required” signal to application
5. App calls createSession again with original initData
— repeat as needed

Along with your proposal to expose the “usable key IDs” this would allow the app to track sessions that it needs to for loading later.

What do you think?

Joe


On Apr 7, 2014, at 2:22 PM, David Dorwin <ddorwin@google.com> wrote:

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