Clarifying key types and persistence

In the call today it became clear there still seems to be disagreement over what types of keys should be supported by the Encrypted Media specification.  

We have had lots of discussion on sharing keys between domains and app instances:
http://lists.w3.org/Archives/Public/public-html-media/2013Nov/0022.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17202

We have had lots of discussion on storing keys persistently:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19785
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750

These are the types of keys I see in common use:
  Key system keys:  Keys that are common across many instances of the key system, not bound to a particular application or device. 
  App and device keys:  Keys that are bound to a particular device and/or application. 
  License chaining keys:  Keys which are used to derive or unwrap content keys. One example would be  domain keys as used by Ultraviolet. 
  Content keys:  Keys used to directly encrypt content.

There seems to be disagreement in the group about which of these key types should be supported. Some of these keys are required for the underlying key systems to function at all. Some of these keys enable business models. Some of these keys are for improving performance. All of these keys have legitimate uses when playing back streaming encrypted content. Supporting all of these key types is within the architectural model of the EME spec. 

The issue of key storage is linked to the issue of supporting non-content keys, as those keys may have a different lifetime than content keys. Key acquisition can be costly in various ways and minimizing the number of key acquisitions is generally a good thing. 

I propose the following changes to Section 1.1.3 “Key Session” to clarify things.

Spec text specifying that sessions refer to the in-memory representation:
“A Key Session, or simply Session, represents the lifetime of the _in-memory representation_ of any license(s)/key(s) it contains and associates all messages related to them.”

Spec text defining the relationship of keys to a Key Session: 
“A Key Session may contain one or more keys. Keys may be identified by key IDs.”

Spec text acknowledging that non-content key types may be supported by the CDM: 
“Keys acquired during the lifetime of a Key Session may be directly or indirectly used in decrypting content.”

Spec text acknowledging that keys may be cached by the CDM if allowed by the browser:
“Any keys acquired by the Key System during the lifetime of a Key Session may be stored as needed by the Key System and allowed by the User Agent.”

This seems like a good topic to hash out a bit before we get to the F2F next week. I don’t think I am saying much that is new here. We have enough bugs filed around different aspects of this subject (17202, 17750, 25200, 25217, 25218, etc.) that I don’t feel the need to file another. However let me know if you think that is not the case.  

Joe