- From: David Dorwin <ddorwin@google.com>
- Date: Thu, 17 Jan 2013 09:14:11 -0800
- To: Mark Watson <watsonm@netflix.com>
- Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <CAHD2rsgzHQ5MsBnb+KkMpSL1zg9Vz7JJeyrZQ=au1qzMEJCdOQ@mail.gmail.com>
On Wed, Jan 16, 2013 at 4:57 PM, Mark Watson <watsonm@netflix.com> wrote: > > On Jan 16, 2013, at 3:40 PM, David Dorwin wrote: > > I filed a couple bugs to track some minor issues with the existing > spec. Comments inline. > > On Wed, Jan 16, 2013 at 1:45 PM, Mark Watson <watsonm@netflix.com> wrote: > >> >> On Jan 16, 2013, at 12:20 PM, David Dorwin wrote: >> >> Hi Mark, >> >> Comments and suggestions inline. >> >> David >> >> On Tue, Jan 15, 2013 at 9:36 AM, Mark Watson <watsonm@netflix.com> wrote: >> >>> Here are some additional changes which I think are required to implement >>> David's alternative proposal for [1] >>> >>> Address [2]. >>> >>> To Section 1.2.3 (SessionID): >>> - To "If session IDs are supported, a new one will be generated each >>> time createSession() successfully creates a MediaKeySession" add "for a new >>> key session." >>> - Change "although the CDM may retain them for longer periods" to >>> "although the CDM may retain key sessions and their associated IDs for >>> longer periods.". >>> - Change "If secure proof of key release is supported each Session ID >>> shall be unique within the origin." to "If the CDM retains key sessions >>> across browsing sessions then each Session ID shall be unique within the >>> origin." >>> >> >> I suggest changing "If" to "When". If a CDM supported both retained >> and unretained sessions, it does not *always* have to use unique IDs. >> >> >> Ok. >> >> >> >>> To David's createSession() proposal (see [1]): >>> - To "Let key request be a key request generated by the CDM using >>> initData, if provided" add "or null if no key request is generated." >>> >> >> So keymessage's message attribute can be null? That affects the event >> definition (3.1) and seems undesirable. My proposed patch just says a >> response is generated and assigned to the message attribute. That can be an >> empty array in the key release case. Do we really need to support null or >> specify *what* the value is? >> >> >> Empty array might work. >> >> If we say that createSession() can retrieve an old session, and we say >> this is generic, in support of "whatever capabilities CDMs want to offer", >> not just specifically for secure proof of key release, then there is the >> case of a session being retrieved in a state where no messages need to be >> sent. For example a persisted session that already has an unexpired license >> matching the supplied initData. But we need to generate some kind of event >> to indicate when the sessionId has been assigned. A null message seemed >> reasonable for this. >> >> Sending keymessage to indicate "the CDM did what the app asked but has > nothing to send to the server" seems useful and null/empty seems like a > good normative definition for this. The only question is whether to use > null or an empty array. If an app gets a null value, it may not handle an > exception and stop working. If it gets an empty message and sends it to the > server, it would seem things have a better chance of succeeding and the > server can detect the issue. I'd like to hear from others that have more > experience with these types of issues and API designs. In the end, it's a > small issue. I opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 to > track this discussion. > >> >> - To "Note: cdm must not use any data, including media data, not >>> provided via initDate" add "or already present in the cdm". >>> >> >> This is a note about creating the key request. Since one is not created >> in your use case, I don't think this applies. More importantly, such a >> change has much larger implications than key release. You can instead add >> "to generate a key request" to the current text if you want. >> >> >> Hmm - I didn't read carefully enough where is refers to "key request". >> If we're making this generic, shouldn't it just be "key message" ? In the >> secure proof of key release case, where I retrieve a session related to a >> deleted key, the message will be the secure proof of key release message. >> > > The purpose of this text was to enforce that the information about the > media that is used to generate a key request be provided via the initData > parameter. This doesn't necessarily apply to other uses of createSession(). > Thus, by adding "to generate a key request", we still enforce this for key > requests while lifting the limitation for other uses. > >> >> >> - Add to the above note: "The CDM may use pre-existing session data >>> that matches the provided type and initData and that is not already >>> associated with a MediaKeySession to initialize the session." >>> >> >> This seems pretty confusing. Is it necessary? Initializing a session is >> key system-/CDM-specific and nothing prevents the scenario in the proposed >> text. >> As mentioned above, the existing normative note is specifically related >> to generation of a key request, so I definitely don't think they should be >> folded together. >> >> >> I think we need to say something too explain how you can retrieve old >> sessions in a CDM-independent way. >> >> >> >>> New FAQ and answer: >>> >>> "Is secure management of the entire key lifecycle supported ? >>> >>> Yes. >>> >>> If a CDM implements the capability to provide a secure proof of key >>> destruction (i.e. a signed attestation from the CDM that a given key has >>> been destroyed), this capability may be exposed by generating a keymessage >>> event when the key is destroyed, containing this attestation. The CDM >>> should persist a record of the session and the key destruction, in case the >>> keymessage cannot be delivered for any reason, for example network loss or >>> inability to deliver messages during page close. This persisted record >>> should be removed when an acknowledgement of the secure proof of key >>> release is received through an update() method. MediaKeySessions associated >>> with such persisted sessions could be retrieved at a later time (e.g. after >>> page unload and later page load) using the createSession() method with null >>> type and initData which implicitly match any persisted session for the page >>> origin." >>> >> >> I think null type is a strong and potentially generally useful value >> that should not be dedicated to key release >> >> >> I'm not suggesting it's dedicated to key release. It would match any >> persisted session, whatever state that is in. >> > > Okay. My statement still applies to "persisted session". I think the use > of "null" would have to really stand out as "of course, that makes sense." > As it stands, we allow null but don't really have a use case and it's > basically there for key system-specific use. Maybe we should make it a > required parameter. I filed > https://www.w3.org/Bugs/Public/show_bug.cgi?id=20691. > >> >> nor have its behavior defined in a FAQ or other non-normative text. >> >> >> Actually it should be defined normatively that "null" matches >> everything, rather than nothing. >> > > |type| is intended to tell the CDM how to interpret |initData|. I'm not > sure "everything" makes sense in this context. > > > I agree 'null' isn't ideal, but I would still like to have a defined way > to retrieve an arbitrary pre-existing session, since that's the missing > generic capability > I'm not sure we need a way to "retrieve an arbitrary pre-existing session". That is a really wide scope for which we can't possibly foresee all the scenarios it might affect. Even type = "persisted" might be too generic. Some key system might have another reason to persist sessions and a defined generic capability could cause ambiguity for apps. I think the class of sessions you really want to be returned is "persisted key releases" or "persisted inactive/closed sessions". > needed to give proof of key release the same status as heartbeat etc. > Can you clarify? I was planning to remove the heartbeat text since it just describes a policy and can be implemented entirely within a key system without adding any special logic to the application. > Do you have any other suggestions ? > > > >> (Key systems may wish to use it for something else.) Is there any >> reason not to use type = "keyrelease" from your original proposal? >> >> >> The original proposal was normative. I agree that we should try and >> find a way where secure proof of key release is not specified normatively, >> but can be built using the generic normative capabilities, in the same way >> as heartbeat etc. But that means we need to define those generic normative >> capabilities - specifically the retrieval of pre-existing sessions, which >> is what I was trying to do above. >> >> Certainly a CDM "can" provide any capability it wants - but I think we >> need at least the basic concepts in the API in order for people to >> understand how the capability makes sense in the context of the API and to >> ensure some commonality across implementations. Otherwise it just looks >> like secure proof of key release is a hack, not something which was >> considered as a reasonable capability to be supported in the API. >> >> >> Minor note: "release" and "destruction" seem to be used >> interchangeably. Is that intentional? >> >> >> No. >> >> >> >>> >>> …Mark >>> >>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199 >>> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622 >>> >>> On Jan 15, 2013, at 8:03 AM, Mark Watson wrote: >>> >>> I think we also need to address >>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622 >>> >>> I will provide text for the FAQ answer. >>> >>> As for requesting old sessions, I think we need to explicitly >>> introduce the idea that CDMs may persist sessions and so createSession() >>> may retrieve a preexisting session based on the type and initData. If the >>> provided type/initData match multiple pre-existing sessions, then any one >>> is returned (and so if they are both null, than any pre-existing session is >>> returned). We should also ask that a keymessage is always sent (even if it >>> might be null) when the session is created so that the user script has some >>> indication when the sessionId is assigned. >>> >>> …Mark >>> >>> On Jan 14, 2013, at 6:19 PM, David Dorwin wrote: >>> >>> Mark and I discussed this and agree that we should try to reuse as >>> much of the base algorithms as possible. Mark would also like a consistent >>> way to retrieve saved key sessions and a FAQ answer. Therefore, I propose >>> the following tasks for resolution for this bug: >>> >>> - Generalize createSession() algorithm so proposed 4.5.1 is covered >>> by it. There are a few statements that assume generation of licenses. >>> - Figure out where to document how to request old sessions, if >>> supported. >>> - Add a FAQ entry about how key release could be supported, similar >>> to the entry for heartbeat. >>> >>> >>> I’ve started working on the createSession() changes. >>> >>> David >>> >>> On Fri, Jan 11, 2013 at 6:10 PM, Mark Watson <watsonm@netflix.com>wrote: >>> >>>> Hi David, >>>> >>>> Please see inline … >>>> >>>> On Jan 11, 2013, at 10:07 AM, David Dorwin wrote: >>>> >>>> Hi Mark, >>>> >>>> The more I think about key release, the more I think it should not be >>>> included in the spec. >>>> >>>> Key management, policies, message protocol & structure, and >>>> key-system or CDM-specific details have been intentionally left out of the >>>> spec. As an example, even the key replacement algorithm is not specified. >>>> Key systems are free to define protocols that include a variety of messages >>>> as long as they fit within the defined APIs (primarily update() and >>>> keymessage). Heartbeat, license renewal, key rotation, etc. can all be >>>> implemented within the existing framework but are not included in the spec. >>>> >>>> The key release proposal does not require altering the existing APIs >>>> or the defined algorithms. It simply defines additional key management, >>>> policy, parameter values, and messages, all of which are key >>>> system-specific. As with the basic message flow, heartbeat, etc., I expect >>>> that key systems will eventually converge on a set of best practices, but >>>> these are not usually defined in a standards-track spec. >>>> >>>> >>>> The proposal does expose functionality at the API level and it's not >>>> all just key-system specific. >>>> >>>> Specifically, the concept of "sessions" and "sessionIds" is an API >>>> concept, not a key-system-specific one. We say that anything that goes on >>>> *within* a session is keysystem-specific. For example, the number of >>>> message exchanges, when they occur in the session, what they do in terms of >>>> keys etc. Heartbeat and key rotation are both examples of where - within a >>>> session - some keysystem-specific magic can go on. >>>> >>>> But the notion of a session itself is part of our API. We define how >>>> you create them in a key-system-specific way. They're created from a >>>> keysystem-independent object (the initData - although within it there may >>>> be multiple keysystem-specific parts). >>>> >>>> The key part of the secure proof of key release proposal is that it >>>> is possible, from outside any session, to retrieve information related to >>>> pre-existing sessions. We're adding a new way to interact with the CDM >>>> outside the context of a session. I don't see how we could do that within >>>> the existing API. >>>> >>>> >>>> Finally are there implementors and CDM providers that intend to >>>> support this? Are there any content providers besides Netflix that intend >>>> to use it? >>>> >>>> >>>> Those are good questions. If the answer to the first one is no when >>>> we get to the appropriate milestones in the specification work, we'll have >>>> to pull this out. Just like anything else. >>>> >>>> I'm not really empowered to speak on behalf of CDM implementors, but >>>> I know that it's not pointless putting this in the specification now. >>>> >>>> …Mark >>>> >>>> >>>> I do not think a Working Draft should include a feature where the >>>> answer to the above questions is "no", especially when it adds non-trivial >>>> complexity to implementations. >>>> >>>> Regards, >>>> David >>>> >>>> On Fri, Jan 11, 2013 at 9:10 AM, Mark Watson <watsonm@netflix.com>wrote: >>>> >>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199 >>>>> >>>>> An updated proposal is attached. >>>>> >>>>> I'd like to propose that we include this text in the First Public >>>>> Working Draft. >>>>> >>>>> [It need not be Section 4, as written, since this interrupts the >>>>> flow of the rest of the document. I leave it to David to suggest the best >>>>> place for it.] >>>>> >>>>> …Mark >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
Received on Thursday, 17 January 2013 17:15:03 UTC