This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The definitions provided in Section 1.1 [1] for Key Session (1.1.3) and Key (1.1.5) are overly restrictive. As they are currently defined they could be interpreted to exclude some use cases, both current and future. * The Key Session definition needs clarification "A Key Session, or simply Session, represents the lifetime of the license(s)/key(s) it contains and associates all messages related to them." It is not clear what "lifetime" means in this context. I believe the intent is to say that while a Session is valid, information about the keys associated with it is accessible. The keys may or may not be alive or usable (see bug 25409). * The Key definition is too restrictive "Such keys may only be provided to the CDM via an update() call." Keys may also be provided directly in the initData so this statement should read: "Such keys may only be provided to the CDM via the createSession(), loadSession() or update() calls." * The License definition is also too restrictive "A license is a key system-specific message that includes one or more decryption key(s) - each associated with a key ID - and potentially other information about key usage." "Decryption keys" is ambiguous here. I believe you mean Keys as in the Key definition. However licenses can also contain keys used for decrypting other keys. Those keys are not associated with key IDs. So we either need a more specific name for "keys used for decrypting media" OR we need to remove the text that says there must be associated key IDs. [1] https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#definitions [2] https://www.w3.org/wiki/HTML/Media_Task_Force#Use_Cases
I agree with the suggested definitions with two exceptions. Text: * The Key definition is too restrictive "Such keys may only be provided to the CDM via an update() call." Keys may also be provided directly in the initData so this statement should read: "Such keys may only be provided to the CDM via the createSession(), loadSession() or update() calls." Even this sentence may be too restrictive. Without knowing how the CDM works, there are techniques to derive keys on the fly based on other (non-key) information or metadata. Therefore, saying that keys must be provided in only one of the 3 calls is still restrictive. The works license seems to imply certain functionality provided by some CDMs. There are CDMs in use today that do no rely on the concept of a License that need to be accommodated as well.
I suggest the following modifications: Key Session: Old: "A Key Session, or simply Session, represents the lifetime of the license(s)/key(s) it contains and associates all messages related to them." New: "A Key Session, or simple Session, provides a context for message exchange with the CDM as a result of which a key or key(s) are made available to be CDM." Key Old: "A key is associated with the session used to provide it to the CDM. (The same key may be present in multiple sessions.) Such keys may only be provided to the CDM via an update() call. (They may later be loaded by loadSession() as part of the stored session data.)" New: "A key is associated with the session used to make it available to the CDM. The same key may be present in multiple sessions." License: Old: "A license is a key system-specific message that includes one or more decryption key(s) - each associated with a key ID - and potentially other information about key usage." New: "A license is key system-specific state information that includes one or more key(s) - each associated with a key ID - and potentially other information about key usage." [Note that 'key' in our document always and only refers to content decryption keys. That doesn't mean other keys can't exist, they're just not described in our specification.]
I like the proposed text in comment 2, with one modification. I think the disclaimer you put at the end of your comment is informative and something like it should be included. For example -- Key Old: "Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within media data. Each key is uniquely identified by a key ID." New: "Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within media data. Each of these keys is uniquely identified by a key ID. Other keys may exist, but they are not covered by this specification."
(In reply to Joe Steele from comment #3) > I like the proposed text in comment 2, with one modification. I think the > disclaimer you put at the end of your comment is informative and something > like it should be included. For example -- > > Key > > Old: "Unless otherwise stated, key refers to a decryption key that can be > used to decrypt blocks within media data. Each key is uniquely identified by > a key ID." > > New: "Unless otherwise stated, key refers to a decryption key that can be > used to decrypt blocks within media data. Each of these keys is uniquely > identified by a key ID. Other keys may exist, but they are not covered by > this specification." Fine for me!
There are multiple proposals, so let me make sure I understand the specific changes. * Key Session * Proposed change: Replace the first sentence with the text in comment #2. This proposal sounds fine to me. * Key * Proposed change: Use "Each of these keys" and add the last sentence. The former is fine. It's unclear what the intent of the latter is. This seems a bit redundant since these are the definitions as used in the spec text and the definition already says "Unless otherwise stated". (It might be a good idea to add an introductory paragraph to the definitions section that says these are the meanings of these terms as used in this spec.) > > License: Proposed change: Use "state information" and remove "decryption" from "key". I'm not sure that "state" is accurate, but that's a minor issue. Is there a reason for removing "decryption"? Note that there is no technical difference because "Key" is defined to be a decryption key.
> > > > License: > Proposed change: Use "state information" and remove "decryption" from "key". > > I'm not sure that "state" is accurate, but that's a minor issue. > > Is there a reason for removing "decryption"? Note that there is no technical > difference because "Key" is defined to be a decryption key. The Key definition says 'unless otherwise stated' and so the qualification 'decryption' in front of 'key' could be interpreted as 'otherwise stating' something. A 'decryption key' is - without further qualification - a very general thing. If we want the license definition to refer to the 'key' definition - so that it is restricted to content decryption keys - then it should just say 'key'.
(In reply to Mark Watson from comment #6) > > > > > > License: > > Proposed change: Use "state information" and remove "decryption" from "key". > > > > I'm not sure that "state" is accurate, but that's a minor issue. > > > > Is there a reason for removing "decryption"? Note that there is no technical > > difference because "Key" is defined to be a decryption key. > > The Key definition says 'unless otherwise stated' and so the qualification > 'decryption' in front of 'key' could be interpreted as 'otherwise stating' > something. A 'decryption key' is - without further qualification - a very > general thing. > > If we want the license definition to refer to the 'key' definition - so that > it is restricted to content decryption keys - then it should just say 'key'. Thanks. Sounds good to me. If we can find a replacement for "state", even better.
Those changes look good to me as well.
Implemented in https://dvcs.w3.org/hg/html-media/rev/ff10d356cc07.