Re: [EME] Updated proposal for secure proof of key release

On Jan 18, 2013, at 1:35 PM, Paul Cotton wrote:

>: "The working group has not yet agreed whether additional normative specification is required in this document for the secure proof of key release feature."

If we add this text then we should add a pointer to the relevant bugs and to a section in the document where the note would be repeated.

The bug we've been using for this discussion is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

The title probably needs amending: the original action was to provide an example and get some feedback on the detailed normative specification of this feature which was already in the Editor's Draft. Now we are discussing whether to include the feature or not.

Adrian/David: do you agree to inclusion of a note as I proposed ? It would be good to have a draft tomorrow morning that we can approve.

…Mark



Sent from my Windows Phone
________________________________
From: Mark Watson
Sent: 18/01/2013 11:49 AM
To: David Dorwin
Cc: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: [EME] Updated proposal for secure proof of key release


On Jan 17, 2013, at 12:17 PM, David Dorwin wrote:


On Thu, Jan 17, 2013 at 11:01 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

It seems we can't find a set of generic capabilities which make secure proof of key release just another CDM behavior like heartbeat, so the path we were on doesn't seem to be working.

So, I'd suggest we keep the secure proof of key release section as I proposed, but cut it down so that it no longer duplicates the createSession algorithm text (now possible with your suggestion). I'll update that proposal today.

I disagree. The group has yet to reach a conclusion on how best to handle the secure proof of key release scenario. Therefore, I think we should continue discussions but not let this block FPWD. The current FPWD still has a variety of loose ends, including some of the base events, format of initData for ISO/MP4, and return value of isTypeSupported(). I don't think there is any reason that key release needs to be fully resolved either, especially when there is not consensus (as there was for the other FPWD bugs).

Since the changes to remove unintentional limitations are minor and require discussion (tracked in bugs mentioned earlier in this thread) and Adrian already has already put a bunch of work into the current FPWD candidate, I propose that we let people have time to review that version and have a CfC for it on Tuesday.

Ok, but we should include a note, either in the SOTD or in the Key Release section (Section 4), along the following lines: "The working group has not yet agreed whether additional normative specification is required in this document for the secure proof of key release feature."

…Mark


…Mark


…Mark