Resolving issues around avoiding key requests

There are three open issues relating to keys being provided in a manner that may allow key requests to be avoided. I am listing them below.
Please review all three issues carefully and respond to this thread with your opinions and questions.

Issue 52 - Remove reference to keys in Initialization Data definition
https://github.com/w3c/encrypted-media/issues/52 <https://github.com/w3c/encrypted-media/issues/52>

The addition of keys to the list of restricted data in the initData was made without any group input as far as I can tell. This restriction flies in the face of the CENC specification which members of this group agreed to support. I believe that the burden should be on the author of this list to provide justification. In the F2F meeting the justification offered for this restriction (as I recall) was that this would lead to an interop problem. I disagree with this and say that this can only lead to an interop problem if in fact those keys are used by the CDM directly, which *could* require the algorithm changes proposed in issue 41. However it does not *necessarily* lead to an interop problem. This edit is also required to allow for the DRM specific key metadata specified by CENC. I believe this issue can be resolved independent of issues 41 and 53.

Issue 41 - Update algorithms to reflect keys being provided in the Initialization Data
https://github.com/w3c/encrypted-media/issues/41 <https://github.com/w3c/encrypted-media/issues/41>

The justification for this proposal is that requesting a key from a license server is expensive. If it is unnecessary to request a key because the keys are already available to the CDM in a manner that complies with all other security/privacy restrictions in the spec, I believe the spec should support not issuing a key request. It has been argued that this will lead to interop issues. I would point out that protocol and policy differences can already cause key requests to happen on a different schedule between Key Systems. This is not fundamentally different and I do not believe that this change will cause much if any additional work for developers. This is blocked by issue 52.

Issue 53 - Allow for long-lived key encryption keys (aka "master" keys) to increase performance
https://github.com/w3c/encrypted-media/issues/53 <https://github.com/w3c/encrypted-media/issues/53>

The justification for this proposal is supporting increased performance for DRMs that can avoid additional license requests. Most if not all DRMs already support some type of key chaining, where a key is either generated on the client or delivered to the client and then that client key is subsequently used for decrypting the content keys provided via key server responses (aka licenses). This chaining today is invisible to the application and is considered “out of scope” for this specification. I am proposing that we bring a variety of key chaining in scope, specifically when more than two keys are involved in the chain for performance reasons. The main problem with the current text is that it assumes that keys acquired during a session will go away once the session is closed, even when there are other active sessions on the same MediaKeys object. This would need to change to make retaining master keys across sessions compliant with the spec. This is blocked by issue 41, since using a master key would imply that a key request is not required in some cases.

Joe