[EME] Moved Key Release section after the Algorithms section.
--- a/encrypted-media/encrypted-media.html Mon May 06 16:54:20 2013 -0700
+++ b/encrypted-media/encrypted-media.html Mon May 06 17:04:40 2013 -0700
@@ -144,13 +144,13 @@
<li><a href="#event-definitions">3.1 Event Definitions</a></li>
<li><a href="#event-summary">3.2 Event Summary</a></li>
</ul></li>
- <li><a href="#key-release">4. Key Release</a></li>
- <li><a href="#algorithms">5. Algorithms</a></li>
+ <li><a href="#algorithms">4. Algorithms</a></li>
<li><ul style="list-style-type:none">
- <li><a href="#algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</a></li>
- <li><a href="#algorithms-enrypted-block">5.2. Encrypted Block Encountered</a></li>
- <li><a href="#algorithms-load">5.3. Addition to Media Element Load Algorithm</a></li>
+ <li><a href="#algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</a></li>
+ <li><a href="#algorithms-enrypted-block">4.2. Encrypted Block Encountered</a></li>
+ <li><a href="#algorithms-load">4.3. Addition to Media Element Load Algorithm</a></li>
</ul></li>
+ <li><a href="#key-release">5. Key Release</a></li>
<li><a href="#simple-decryption">6. Simple Decryption</a></li>
<li><ul style="list-style-type:none">
<li><a href="#simple-decryption-clear-key">6.1. Clear Key</a></li>
@@ -751,30 +751,10 @@
</tbody>
</table>
- <h2 id="key-release">4. Key Release</h2>
- <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
- <h3 id="key-release-intro">4.1. Introduction</h3>
- <p><i>This section is non-normative.</i></p>
- <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
- This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
- Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
- Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
- </p>
-
- <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
- The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
- Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
- This acknowledgement must also be in the form of a CDM-specific message.
- </p>
-
- <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
- This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
- Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
- </p>
- <h2 id="algorithms">5. Algorithms</h2>
+ <h2 id="algorithms">4. Algorithms</h2>
- <h3 id="algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</h3>
+ <h3 id="algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</h3>
<p>The following steps are run when the <a href="#media-element">media element</a> encounters a source that may contain encrypted blocks or streams during the <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>:</p>
<ol>
@@ -837,7 +817,7 @@
<li><p><i>Continue Normal Flow</i>: Continue with the existing media element's <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>.</p></li>
</ol>
- <h3 id="algorithms-enrypted-block">5.2. Encrypted Block Encountered</h3>
+ <h3 id="algorithms-enrypted-block">4.2. Encrypted Block Encountered</h3>
<p>The following steps are run when the <a href="#media-element">media element</a> encounters a block <span class="non-normative">(i.e. frame)</span> of encrypted <a href="http://www.w3.org/TR/html5/embedded-content-0.html#media-data">media data</a> during the <a href="http://www.w3.org/TR/html5/embedded-content-0.html#concept-media-load-resource">resource fetch algorithm</a>:</p>
<ol>
@@ -913,7 +893,7 @@
<li class="non-normative">The media element leaves this state when seeking but could re-enter it if the same conditions exist.</li>
</ul>
- <h3 id="algorithms-load">5.3. Addition to Media Element Load Algorithm</h3>
+ <h3 id="algorithms-load">4.3. Addition to Media Element Load Algorithm</h3>
<p>The following step is added to the existing <a href="http://www.w3.org/TR/html5/embedded-content-0.html#media-element-load-algorithm">media element load algorithm</a>:</p>
<ul>
<li>
@@ -923,6 +903,28 @@
</ul>
+ <h2 id="key-release">5. Key Release</h2>
+ <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
+ <h3 id="key-release-intro">5.1. Introduction</h3>
+ <p><i>This section is non-normative.</i></p>
+ <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
+ This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
+ Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
+ Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
+ </p>
+
+ <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
+ The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
+ Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
+ This acknowledgement must also be in the form of a CDM-specific message.
+ </p>
+
+ <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
+ This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
+ Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
+ </p>
+
+
<h2 id="simple-decryption">6. Simple Decryption</h2>
<p>All user agents must support the simple decryption capabilities described in this section regardless of whether they support a more advanced <a href="#cdm">CDM</a>.
<span class="non-normative">This ensures that there is a common baseline level of protection that is guaranteed to be supported in all user agents, including those that are entirely open source.
--- a/encrypted-media/encrypted-media.xml Mon May 06 16:54:20 2013 -0700
+++ b/encrypted-media/encrypted-media.xml Mon May 06 17:04:40 2013 -0700
@@ -141,13 +141,13 @@
<li><a href="#event-definitions">3.1 Event Definitions</a></li>
<li><a href="#event-summary">3.2 Event Summary</a></li>
</ul></li>
- <li><a href="#key-release">4. Key Release</a></li>
- <li><a href="#algorithms">5. Algorithms</a></li>
+ <li><a href="#algorithms">4. Algorithms</a></li>
<li><ul style="list-style-type:none">
- <li><a href="#algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</a></li>
- <li><a href="#algorithms-enrypted-block">5.2. Encrypted Block Encountered</a></li>
- <li><a href="#algorithms-load">5.3. Addition to Media Element Load Algorithm</a></li>
+ <li><a href="#algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</a></li>
+ <li><a href="#algorithms-enrypted-block">4.2. Encrypted Block Encountered</a></li>
+ <li><a href="#algorithms-load">4.3. Addition to Media Element Load Algorithm</a></li>
</ul></li>
+ <li><a href="#key-release">5. Key Release</a></li>
<li><a href="#simple-decryption">6. Simple Decryption</a></li>
<li><ul style="list-style-type:none">
<li><a href="#simple-decryption-clear-key">6.1. Clear Key</a></li>
@@ -706,30 +706,10 @@
</tbody>
</table>
- <h2 id="key-release">4. Key Release</h2>
- <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
- <h3 id="key-release-intro">4.1. Introduction</h3>
- <non-normative-section/>
- <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
- This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
- Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
- Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
- </p>
-
- <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
- The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
- Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
- This acknowledgement must also be in the form of a CDM-specific message.
- </p>
-
- <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
- This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
- Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
- </p>
- <h2 id="algorithms">5. Algorithms</h2>
+ <h2 id="algorithms">4. Algorithms</h2>
- <h3 id="algorithms-encrypted-stream">5.1. First Time a Key Reference is Encountered</h3>
+ <h3 id="algorithms-encrypted-stream">4.1. First Time a Key Reference is Encountered</h3>
<p>The following steps are run when the <a href="#media-element">media element</a> encounters a source that may contain encrypted blocks or streams during the <resource-fetch-algorithm/>:</p>
<ol>
@@ -787,7 +767,7 @@
<li><p><i>Continue Normal Flow</i>: Continue with the existing media element's <resource-fetch-algorithm/>.</p></li>
</ol>
- <h3 id="algorithms-enrypted-block">5.2. Encrypted Block Encountered</h3>
+ <h3 id="algorithms-enrypted-block">4.2. Encrypted Block Encountered</h3>
<p>The following steps are run when the <a href="#media-element">media element</a> encounters a block <span class="non-normative">(i.e. frame)</span> of encrypted <videoanchor name="media-data">media data</videoanchor> during the <resource-fetch-algorithm/>:</p>
<ol>
@@ -858,7 +838,7 @@
<li class="non-normative">The media element leaves this state when seeking but could re-enter it if the same conditions exist.</li>
</ul>
- <h3 id="algorithms-load">5.3. Addition to Media Element Load Algorithm</h3>
+ <h3 id="algorithms-load">4.3. Addition to Media Element Load Algorithm</h3>
<p>The following step is added to the existing <media-element-load-algorithm/>:</p>
<ul>
<li><p>Clear the <coderef>keys</coderef> attribute for this <a href="#media-element">media element</a>.</p>
@@ -867,6 +847,28 @@
</ul>
+ <h2 id="key-release">5. Key Release</h2>
+ <p class="non-normative">Note: it is an open issue whether further normative specification of this feature is required. See <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199">Bug 17199</a>.</p>
+ <h3 id="key-release-intro">5.1. Introduction</h3>
+ <non-normative-section/>
+ <p>The above sections provide for delivery of key/license information to a <a href="#cdm">Content Decryption Module</a>.
+ This section provides for management of the entire key/license lifecycle, that is, secure proof of key release.
+ Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted.
+ Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.
+ </p>
+
+ <p>Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified.
+ The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed.
+ Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received.
+ This acknowledgement must also be in the form of a CDM-specific message.
+ </p>
+
+ <p>The mechanism for secure proof of key release operates outside the scope of any <a href="#media-element">media element</a>.
+ This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed.
+ Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.
+ </p>
+
+
<h2 id="simple-decryption">6. Simple Decryption</h2>
<p>All user agents must support the simple decryption capabilities described in this section regardless of whether they support a more advanced <a href="#cdm">CDM</a>.
<span class="non-normative">This ensures that there is a common baseline level of protection that is guaranteed to be supported in all user agents, including those that are entirely open source.