��<!doctype html><html lang="en"> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <title>DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX)</title> <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport"> <style data-fill-with="stylesheet">/****************************************************************************** * Style sheet for the W3C specifications * * * Special classes handled by this style sheet include: * * Indices * - .toc for the Table of Contents (<ol class="toc">) * + <span class="secno"> for the section numbers * - #toc for the Table of Contents (<nav id="toc">) * - ul.index for Indices (<a href="#ref">term</a><span>, in �/ N.M</span>) * - table.index for Index Tables (e.g. for properties or elements) * * Structural Markup * - table.data for general data tables * -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results ! * -> use <table class='complex data'> for extra-complex tables * -> use <td class='long'> for paragraph-length cell content * -> use <td class='pre'> when manual line breaks/indentation would help readability * - dl.switch for switch statements * - ol.algorithm for algorithms (helps to visualize nesting) * - .figure and .caption (HTML4) and figure and figcaption (HTML5) * -> .sidefigure for right-floated figures * - ins/del * -> ins/del.c### for candidate and proposed changes (amendments) * * Code * - pre and code * * Special Sections * - .note for informative notes (div, p, span, aside, details) * - .example for informative examples (div, p, pre, span) * - .issue for issues (div, p, span) * - .advisement for loud normative statements (div, p, strong) * - .annoying-warning for spec obsoletion notices (div, aside, details) * - .correction for "candidate corrections" (div, aside, details, section) * - .addition for "candidate additions" (div, aside, details, section) * - .correction.proposed for "proposed corrections" (div, aside, details, section) * - .addition.proposed for "proposed additions" (div, aside, details, section) * * Definition Boxes * - pre.def for WebIDL definitions * - table.def for tables that define other entities (e.g. CSS properties) * - dl.def for definition lists that define other entitles (e.g. HTML elements) * * Numbering * - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>) * - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>) * - ::before styled for CSS-generated issue/example/figure numbers: * -> Documents wishing to use this only need to add * figcaption::before, * .caption::before { content: "Figure " counter(figure) " "; } * .example::before { content: "Example " counter(example) " "; } * .issue::before { content: "Issue " counter(issue) " "; } * * Header Stuff (ignore, just don't conflict with these classes) * - .head for the header * - .copyright for the copyright * * Outdated warning for old specs * * Miscellaneous * - .overlarge for things that should be as wide as possible, even if * that overflows the body text area. This can be used on an item or * on its container, depending on the effect desired. * Note that this styling basically doesn't help at all when printing, * since A4 paper isn't much wider than the max-width here. * It's better to design things to fit into a narrower measure if possible. * * - js-added ToC jump links (see fixup.js) * ******************************************************************************/ /* color variables included separately for reliability */ /******************************************************************************/ /* Body */ /******************************************************************************/ html { } body { counter-reset: example figure issue; /* Layout */ max-width: 50em; /* limit line length to 50em for readability */ margin: 0 auto; /* center text within page */ padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */ padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag */ /* Typography */ line-height: 1.5; font-family: sans-serif; widows: 2; orphans: 2; word-wrap: break-word; overflow-wrap: break-word; hyphens: auto; color: black; color: var(--text); background: white top left fixed no-repeat; background: var(--bg) top left fixed no-repeat; background-size: 25px auto; } /******************************************************************************/ /* Front Matter & Navigation */ /******************************************************************************/ /** Header ********************************************************************/ div.head { margin-bottom: 1em; } div.head hr { border-style: solid; } div.head h1 { font-weight: bold; margin: 0 0 .1em; font-size: 220%; } div.head h2 { margin-bottom: 1.5em;} /** W3C Logo ******************************************************************/ .head .logo { float: right; margin: 0.4rem 0 0.2rem .4rem; } .head img[src*="logos/W3C"] { display: block; border: solid #1a5e9a; border: solid var(--logo-bg); border-width: .65rem .7rem .6rem; border-radius: .4rem; background: #1a5e9a; background: var(--logo-bg); color: white; color: var(--logo-text); font-weight: bold; } .head a:hover > img[src*="logos/W3C"], .head a:focus > img[src*="logos/W3C"] { opacity: .8; } .head a:active > img[src*="logos/W3C"] { background: #c00; background: var(--logo-active-bg); border-color: #c00; border-color: var(--logo-active-bg); } /* see also additional rules in Link Styling section */ /** Copyright *****************************************************************/ p.copyright, p.copyright small { font-size: small; } /** Back to Top / ToC Toggle **************************************************/ @media print { #toc-nav { display: none; } } @media not print { #toc-nav { position: fixed; z-index: 3; bottom: 0; left: 0; margin: 0; min-width: 1.33em; border-top-right-radius: 2rem; box-shadow: 0 0 2px; font-size: 1.5em; } #toc-nav > a { display: block; white-space: nowrap; height: 1.33em; padding: .1em 0.3em; margin: 0; box-shadow: 0 0 2px; border: none; border-top-right-radius: 1.33em; color: #707070; color: var(--tocnav-normal-text); background: white; background: var(--tocnav-normal-bg); } #toc-nav > a:hover, #toc-nav > a:focus { color: black; color: var(--tocnav-hover-text); background: #f8f8f8; background: var(--tocnav-hover-bg); } #toc-nav > a:active { color: #c00; color: var(--tocnav-active-text); background: white; background: var(--tocnav-active-bg); } #toc-nav > #toc-jump { padding-bottom: 2em; margin-bottom: -1.9em; } /* statusbar gets in the way on keyboard focus; remove once browsers fix */ #toc-nav > a[href="#toc"]:not(:hover):focus:last-child { padding-bottom: 1.5rem; } #toc-nav:not(:hover) > a:not(:focus) > span + span { /* Ideally this uses :focus-within on #toc-nav */ display: none; } #toc-nav > a > span + span { padding-right: 0.2em; } } /** ToC Sidebar ***************************************************************/ /* Floating sidebar */ @media screen { body.toc-sidebar #toc { position: fixed; top: 0; bottom: 0; left: 0; width: 23.5em; max-width: 80%; max-width: calc(100% - 2em - 26px); overflow: auto; padding: 0 1em; padding-left: 42px; padding-left: calc(1em + 26px); color: black; color: var(--tocsidebar-text); background: inherit; background-color: #f7f8f9; background-color: var(--tocsidebar-bg); z-index: 1; box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset; box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset; } body.toc-sidebar #toc h2 { margin-top: .8rem; font-variant: small-caps; font-variant: all-small-caps; text-transform: lowercase; font-weight: bold; color: gray; color: hsla(203,20%,40%,.7); color: var(--tocsidebar-heading-text); } body.toc-sidebar #toc-jump:not(:focus) { width: 0; height: 0; padding: 0; position: absolute; overflow: hidden; } } /* Hide main scroller when only the ToC is visible anyway */ @media screen and (max-width: 28em) { body.toc-sidebar { overflow: hidden; } } /* Sidebar with its own space */ @media screen and (min-width: 78em) { body:not(.toc-inline) #toc { position: fixed; top: 0; bottom: 0; left: 0; width: 23.5em; overflow: auto; padding: 0 1em; padding-left: 42px; padding-left: calc(1em + 26px); color: black; color: var(--tocsidebar-text); background: inherit; background-color: #f7f8f9; background-color: var(--tocsidebar-bg); z-index: 1; box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset; box-shadow: -.1em 0 .25em var(--tocsidebar-shadow) inset; } body:not(.toc-inline) #toc h2 { margin-top: .8rem; font-variant: small-caps; font-variant: all-small-caps; text-transform: lowercase; font-weight: bold; color: gray; color: hsla(203,20%,40%,.7); color: var(--tocsidebar-heading-text); } body:not(.toc-inline) { padding-left: 29em; } /* See also Overflow section at the bottom */ body:not(.toc-inline) #toc-jump:not(:focus) { width: 0; height: 0; padding: 0; position: absolute; overflow: hidden; } } @media screen and (min-width: 90em) { body:not(.toc-inline) { margin: 0 4em; } } /******************************************************************************/ /* Sectioning */ /******************************************************************************/ /** Headings ******************************************************************/ h1, h2, h3, h4, h5, h6, dt { page-break-after: avoid; page-break-inside: avoid; font: 100% sans-serif; /* Reset all font styling to clear out UA styles */ font-family: inherit; /* Inherit the font family. */ line-height: 1.2; /* Keep wrapped headings compact */ hyphens: manual; /* Hyphenated headings look weird */ } h2, h3, h4, h5, h6 { margin-top: 3rem; } h1, h2, h3 { color: #005A9C; color: var(--heading-text); } h1 { font-size: 170%; } h2 { font-size: 140%; } h3 { font-size: 120%; } h4 { font-weight: bold; } h5 { font-style: italic; } h6 { font-variant: small-caps; } dt { font-weight: bold; } /** Subheadings ***************************************************************/ h1 + h2, #profile-and-date { /* #profile-and-date is a subtitle in an H2 under the H1 */ margin-top: 0; } h2 + h3, h3 + h4, h4 + h5, h5 + h6 { margin-top: 1.2em; /* = 1 x line-height */ } /** Section divider ***********************************************************/ :not(.head) > :not(.head) + hr { font-size: 1.5em; text-align: center; margin: 1em auto; height: auto; color: black; color: var(--hr-text); border: transparent solid 0; background: transparent; } :not(.head) > hr::before { content: "\2727\2003\2003\2727\2003\2003\2727"; } /******************************************************************************/ /* Paragraphs and Lists */ /******************************************************************************/ p { margin: 1em 0; } dd > p:first-child, li > p:first-child { margin-top: 0; } ul, ol { margin-left: 0; padding-left: 2em; } li { margin: 0.25em 0 0.5em; padding: 0; } dl dd { margin: 0 0 .5em 2em; } .head dd + dd { /* compact for header */ margin-top: -.5em; } /* Style for algorithms */ ol.algorithm ol:not(.algorithm), .algorithm > ol ol:not(.algorithm) { border-left: 0.5em solid #DEF; border-left: 0.5em solid var(--algo-border); } /* Put nice boxes around each algorithm. */ [data-algorithm]:not(.heading) { padding: .5em; border: thin solid #ddd; border: thin solid var(--algo-border); border-radius: .5em; margin: .5em calc(-0.5em - 1px); } [data-algorithm]:not(.heading) > :first-child { margin-top: 0; } [data-algorithm]:not(.heading) > :last-child { margin-bottom: 0; } /* Style for switch/case <dl>s */ dl.switch > dd > ol.only, dl.switch > dd > .only > ol { margin-left: 0; } dl.switch > dd > ol.algorithm, dl.switch > dd > .algorithm > ol { margin-left: -2em; } dl.switch { padding-left: 2em; } dl.switch > dt { text-indent: -1.5em; margin-top: 1em; } dl.switch > dt + dt { margin-top: 0; } dl.switch > dt::before { content: '\21AA'; padding: 0 0.5em 0 0; display: inline-block; width: 1em; text-align: right; line-height: 0.5em; } /** Terminology Markup ********************************************************/ /******************************************************************************/ /* Inline Markup */ /******************************************************************************/ /** Terminology Markup ********************************************************/ dfn { /* Defining instance */ font-weight: bolder; } a > i { /* Instance of term */ font-style: normal; } dt dfn code, code.idl { font-size: inherit; } dfn var { font-style: normal; } /** Change Marking ************************************************************/ del { color: #aa0000; color: var(--del-text); background: transparent; background: var(--del-bg); text-decoration: line-through; } ins { color: #006100; color: var(--ins-text); background: transparent; background: var(--ins-bg); text-decoration: underline; } /* for amendments (candidate/proposed changes) */ .amendment ins, .correction ins, .addition ins, ins[class^=c] { text-decoration-style: dotted; } .amendment del, .correction del, .addition del, del[class^=c] { text-decoration-style: dotted; } .amendment.proposed ins, .correction.proposed ins, .addition.proposed ins, ins[class^=c].proposed { text-decoration-style: double; } .amendment.proposed del, .correction.proposed del, .addition.proposed del, del[class^=c].proposed { text-decoration-style: double; } /** Miscellaneous improvements to inline formatting ***************************/ sup { vertical-align: super; font-size: 80% } /******************************************************************************/ /* Code */ /******************************************************************************/ /** General monospace/pre rules ***********************************************/ pre, code, samp { font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace; font-size: .9em; hyphens: none; text-transform: none; text-align: left; text-align: start; font-variant: normal; orphans: 3; widows: 3; page-break-before: avoid; } pre code, code code { font-size: 100%; } pre { margin-top: 1em; margin-bottom: 1em; overflow: auto; } /** Inline Code fragments *****************************************************/ /* Do something nice. */ /******************************************************************************/ /* Links */ /******************************************************************************/ /** General Hyperlinks ********************************************************/ /* We hyperlink a lot, so make it less intrusive */ a[href] { color: #034575; color: var(--a-normal-text); text-decoration: underline #707070; text-decoration: underline var(--a-normal-underline); text-decoration-skip-ink: none; } a:visited { color: #034575; color: var(--a-visited-text); text-decoration-color: #bbb; text-decoration-color: var(--a-visited-underline); } /* Indicate interaction with the link */ a[href]:focus, a[href]:hover { text-decoration-thickness: 2px; } a[href]:active { color: #c00; color: var(--a-active-text); text-decoration-color: #c00; text-decoration-color: var(--a-active-underline); } /* Backout above styling for W3C logo */ .head .logo, .head .logo a { border: none; text-decoration: none; background: transparent; } /******************************************************************************/ /* Images */ /******************************************************************************/ img { border-style: none; } img, svg { /* Intentionally not color-scheme aware. */ background: white; } /* For autogen numbers, add .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; } */ figure, .figure, .sidefigure { page-break-inside: avoid; text-align: center; margin: 2.5em 0; } .figure img, .sidefigure img, figure img, .figure object, .sidefigure object, figure object { max-width: 100%; margin: auto; height: auto; } .figure pre, .sidefigure pre, figure pre { text-align: left; display: table; margin: 1em auto; } .figure table, figure table { margin: auto; } @media screen and (min-width: 20em) { .sidefigure { float: right; width: 50%; margin: 0 0 0.5em 0.5em; } } .caption, figcaption, caption { font-style: italic; font-size: 90%; } .caption::before, figcaption::before, figcaption > .marker { font-weight: bold; } .caption, figcaption { counter-increment: figure; } /* DL list is indented 2em, but figure inside it is not */ dd > .figure, dd > figure { margin-left: -2em; } /******************************************************************************/ /* Colored Boxes */ /******************************************************************************/ .issue, .note, .example, .assertion, .advisement, blockquote, .amendment, .correction, .addition { margin: 1em auto; padding: .5em; border: .5em; border-left-style: solid; page-break-inside: avoid; } span.issue, span.note { padding: .1em .5em .15em; border-right-style: solid; } blockquote > :first-child, .note > p:first-child, .issue > p:first-child, .amendment > p:first-child, .correction > p:first-child, .addition > p:first-child { margin-top: 0; } blockquote > :last-child, .note > p:last-child, .issue > p:last-child, .amendment > p:last-child, .correction > p:last-child, .addition > p:last-child { margin-bottom: 0; } .issue::before, .issue > .marker, .example::before, .example > .marker, .note::before, .note > .marker, details.note > summary > .marker, .amendment::before, .amendment > .marker, details.amendment > summary > .marker, .addition::before, .addition > .marker, addition.amendment > summary > .marker, .correction::before, .correction > .marker, correction.amendment > summary > .marker { text-transform: uppercase; padding-right: 1em; } .example::before, .example > .marker { display: block; padding-right: 0em; } /** Blockquotes ***************************************************************/ blockquote { border-color: silver; border-color: var(--blockquote-border); background: transparent; background: var(--blockquote-bg); color: currentcolor; color: var(--blockquote-text); } /** Open issue ****************************************************************/ .issue { border-color: #e05252; border-color: var(--issue-border); background: #fbe9e9; background: var(--issue-bg); color: black; color: var(--issue-text); counter-increment: issue; overflow: auto; } .issue::before, .issue > .marker { color: #831616; color: var(--issueheading-text); } /* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers, or use class="marker" to mark up the issue number in source. */ /** Example *******************************************************************/ .example { border-color: #e0cb52; border-color: var(--example-border); background: #fcfaee; background: var(--example-bg); color: black; color: var(--example-text); counter-increment: example; overflow: auto; clear: both; } .example::before, .example > .marker { color: #574b0f; color: var(--exampleheading-text); } /* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers, or use class="marker" to mark up the example number in source. */ /** Non-normative Note ********************************************************/ .note { border-color: #52e052; border-color: var(--note-border); background: #e9fbe9; background: var(--note-bg); color: black; color: var(--note-text); overflow: auto; } .note::before, .note > .marker, details.note > summary { color: hsl(120, 70%, 30%); color: var(--noteheading-text); } /* Add .note::before { content: "Note "; } for autogen label, or use class="marker" to mark up the label in source. */ details.note[open] > summary { border-bottom: 1px silver solid; border-bottom: 1px var(--notesummary-underline) solid; } /** Assertion Box *************************************************************/ /* for assertions in algorithms */ .assertion { border-color: #AAA; border-color: var(--assertion-border); background: #EEE; background: var(--assertion-bg); color: black; color: var(--assertion-text); } /** Advisement Box ************************************************************/ /* for attention-grabbing normative statements */ .advisement { border-color: orange; border-color: var(--advisement-border); border-style: none solid; background: #fec; background: var(--advisement-bg); color: black; color: var(--advisement-text); } strong.advisement { display: block; text-align: center; } .advisement::before, .advisement > .marker { color: #b35f00; color: var(--advisementheading-text); } /** Amendment Box *************************************************************/ .amendment, .correction, .addition { border-color: #330099; border-color: var(--amendment-border); background: #F5F0FF; background: var(--amendment-bg); color: black; color: var(--amendment-text); } .amendment.proposed, .correction.proposed, .addition.proposed { border-style: solid; border-block-width: 0.25em; } .amendment::before, .amendment > .marker, details.amendment > summary::before, details.amendment > summary > .marker, .correction::before, .correction > .marker, details.correction > summary::before, details.correction > summary > .marker, .addition::before, .addition > .marker, details.addition > summary::before, details.addition > summary > .marker { color: #220066; color: var(--amendmentheading-text); } .amendment.proposed::before, .amendment.proposed > .marker, details.amendment.proposed > summary::before, details.amendment.proposed > summary > .marker, .correction.proposed::before, .correction.proposed > .marker, details.correction.proposed > summary::before, details.correction.proposed > summary > .marker, .addition.proposed::before, .addition.proposed > .marker, details.addition.proposed > summary::before, details.addition.proposed > summary > .marker { font-weight: bold; } /** Spec Obsoletion Notice ****************************************************/ /* obnoxious obsoletion notice for older/abandoned specs. */ details { display: block; } summary { font-weight: bolder; } .annoying-warning:not(details), details.annoying-warning:not([open]) > summary, details.annoying-warning[open] { background: hsla(40,100%,50%,0.95); background: var(--warning-bg); color: black; color: var(--warning-text); padding: .75em 1em; border: red; border: var(--warning-border); border-style: solid none; box-shadow: 0 2px 8px black; text-align: center; } .annoying-warning :last-child { margin-bottom: 0; } @media not print { details.annoying-warning[open] { position: fixed; left: 0; right: 0; bottom: 2em; z-index: 1000; } } details.annoying-warning:not([open]) > summary { text-align: center; } /** Entity Definition Boxes ***************************************************/ .def { padding: .5em 1em; background: #def; background: var(--def-bg); margin: 1.2em 0; border-left: 0.5em solid #8ccbf2; border-left: 0.5em solid var(--def-border); color: black; color: var(--def-text); } /******************************************************************************/ /* Tables */ /******************************************************************************/ th, td { text-align: left; text-align: start; } /** Property/Descriptor Definition Tables *************************************/ table.def { /* inherits .def box styling, see above */ width: 100%; border-spacing: 0; } table.def td, table.def th { padding: 0.5em; vertical-align: baseline; border-bottom: 1px solid #bbd7e9; border-bottom: 1px solid var(--defrow-border); } table.def > tbody > tr:last-child th, table.def > tbody > tr:last-child td { border-bottom: 0; } table.def th { font-style: italic; font-weight: normal; padding-left: 1em; width: 3em; } /* For when values are extra-complex and need formatting for readability */ table td.pre { white-space: pre-wrap; } /* A footnote at the bottom of a def table */ table.def td.footnote { padding-top: 0.6em; } table.def td.footnote::before { content: " "; display: block; height: 0.6em; width: 4em; border-top: thin solid; } /** Data tables (and properly marked-up index tables) *************************/ /* <table class="data"> highlights structural relationships in a table when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute) Use class="complex data" for particularly complicated tables -- (This will draw more lines: busier, but clearer.) Use class="long" on table cells with paragraph-like contents (This will adjust text alignment accordingly.) Alternately use class="longlastcol" on tables, to have the last column assume "long". */ table { word-wrap: normal; overflow-wrap: normal; hyphens: manual; } table.data, table.index { margin: 1em auto; border-collapse: collapse; border: hidden; width: 100%; } table.data caption, table.index caption { max-width: 50em; margin: 0 auto 1em; } table.data td, table.data th, table.index td, table.index th { padding: 0.5em 1em; border-width: 1px; border-color: silver; border-color: var(--datacell-border); border-top-style: solid; } table.data thead td:empty { padding: 0; border: 0; } table.data thead, table.index thead, table.data tbody, table.index tbody { border-bottom: 2px solid; } table.data colgroup, table.index colgroup { border-left: 2px solid; } table.data tbody th:first-child, table.index tbody th:first-child { border-right: 2px solid; border-top: 1px solid silver; border-top: 1px solid var(--datacell-border); padding-right: 1em; } table.data th[colspan], table.data td[colspan] { text-align: center; } table.complex.data th, table.complex.data td { border: 1px solid silver; border: 1px solid var(--datacell-border); text-align: center; } table.data.longlastcol td:last-child, table.data td.long { vertical-align: baseline; text-align: left; } table.data img { vertical-align: middle; } /* Alternate table alignment rules table.data, table.index { text-align: center; } table.data thead th[scope="row"], table.index thead th[scope="row"] { text-align: right; } table.data tbody th:first-child, table.index tbody th:first-child { text-align: right; } Possible extra rowspan handling table.data tbody th[rowspan]:not([rowspan='1']), table.index tbody th[rowspan]:not([rowspan='1']), table.data tbody td[rowspan]:not([rowspan='1']), table.index tbody td[rowspan]:not([rowspan='1']) { border-left: 1px solid silver; } table.data tbody th[rowspan]:first-child, table.index tbody th[rowspan]:first-child, table.data tbody td[rowspan]:first-child, table.index tbody td[rowspan]:first-child{ border-left: 0; border-right: 1px solid silver; } */ /******************************************************************************/ /* Indices */ /******************************************************************************/ /** Table of Contents *********************************************************/ .toc a { /* More spacing; use padding to make it part of the click target. */ padding: 0.1rem 1px 0; /* Larger, more consistently-sized click target */ display: block; /* Switch to using border-bottom for underlines */ text-decoration: none; border-bottom: 1px solid; /* Reverse color scheme */ color: black; color: var(--toclink-text); border-color: #3980b5; border-color: var(--toclink-underline); } .toc a:visited { color: black; color: var(--toclink-visited-text); border-color: #054572; border-color: var(--toclink-visited-underline); } .toc a:focus, .toc a:hover { background: rgba(75%, 75%, 75%, .25); background: var(--a-hover-bg); border-bottom-width: 3px; margin-bottom: -2px; } .toc a:not(:focus):not(:hover) { /* Allow colors to cascade through from link styling */ border-bottom-color: transparent; } .toc, .toc ol, .toc ul, .toc li { list-style: none; /* Numbers must be inlined into source */ /* because generated content isn't search/selectable and markers can't do multilevel yet */ margin: 0; padding: 0; } .toc { line-height: 1.1em; } /* ToC not indented until third level, but font style & margins show hierarchy */ .toc > li { font-weight: bold; } .toc > li li { font-weight: normal; } .toc > li li li { font-size: 95%; } .toc > li li li li { font-size: 90%; } .toc > li li li li li { font-size: 85%; } /* @supports not (display:grid) { */ .toc > li { margin: 1.5rem 0; } .toc > li li { margin: 0.3rem 0; } .toc > li li li { margin-left: 2rem; } /* Section numbers in a column of their own */ .toc .secno { float: left; width: 4rem; white-space: nowrap; } .toc > li li li li .secno { font-size: 85%; } .toc > li li li li li .secno { font-size: 100%; } .toc li { clear: both; } :not(li) > .toc { margin-left: 5rem; } .toc .secno { margin-left: -5rem; } .toc > li li li .secno { margin-left: -7rem; } .toc > li li li li .secno { margin-left: -9rem; } .toc > li li li li li .secno { margin-left: -11rem; } /* Tighten up indentation in narrow ToCs */ @media (max-width: 30em) { :not(li) > .toc { margin-left: 4rem; } .toc .secno { margin-left: -4rem; } .toc > li li li { margin-left: 1rem; } .toc > li li li .secno { margin-left: -5rem; } .toc > li li li li .secno { margin-left: -6rem; } .toc > li li li li li .secno { margin-left: -7rem; } } /* Loosen it on wide screens */ @media screen and (min-width: 78em) { body:not(.toc-inline) :not(li) > .toc { margin-left: 4rem; } body:not(.toc-inline) .toc .secno { margin-left: -4rem; } body:not(.toc-inline) .toc > li li li { margin-left: 1rem; } body:not(.toc-inline) .toc > li li li .secno { margin-left: -5rem; } body:not(.toc-inline) .toc > li li li li .secno { margin-left: -6rem; } body:not(.toc-inline) .toc > li li li li li .secno { margin-left: -7rem; } } /* } */ @supports (display:grid) and (display:contents) { /* Use #toc over .toc to override non-@supports rules. */ #toc { display: grid; align-content: start; grid-template-columns: auto 1fr; grid-column-gap: 1rem; column-gap: 1rem; grid-row-gap: .6rem; row-gap: .6rem; } #toc h2 { grid-column: 1 / -1; margin-bottom: 0; } #toc ol, #toc li, #toc a { display: contents; /* Switch <a> to subgrid when supported */ } #toc span { margin: 0; } #toc > .toc > li > a > span { /* The spans of the top-level list, comprising the first items of each top-level section. */ margin-top: 1.1rem; } #toc#toc .secno { /* Ugh, need more specificity to override base.css */ grid-column: 1; width: auto; margin-left: 0; } #toc .content { grid-column: 2; width: auto; margin-right: 1rem; border-bottom: 3px solid transparent; margin-bottom: -3px; } #toc .content:hover, #toc .content:focus { background: rgba(75%, 75%, 75%, .25); background: var(--a-hover-bg); border-bottom-color: #054572; border-bottom-color: var(--toclink-underline); } #toc li li li .content { margin-left: 1rem; } #toc li li li li .content { margin-left: 2rem; } } /** Index *********************************************************************/ /* Index Lists: Layout */ ul.index { margin-left: 0; columns: 15em; text-indent: 1em hanging; } ul.index li { margin-left: 0; list-style: none; break-inside: avoid; } ul.index li li { margin-left: 1em; } ul.index dl { margin-top: 0; } ul.index dt { margin: .2em 0 .2em 20px;} ul.index dd { margin: .2em 0 .2em 40px;} /* Index Lists: Typography */ ul.index ul, ul.index dl { font-size: smaller; } @media not print { ul.index li a + span { white-space: nowrap; color: transparent; } ul.index li a:hover + span, ul.index li a:focus + span { color: #707070; color: var(--indexinfo-text); } } /** Index Tables *****************************************************/ /* See also the data table styling section, which this effectively subclasses */ table.index { font-size: small; border-collapse: collapse; border-spacing: 0; text-align: left; margin: 1em 0; } table.index td, table.index th { padding: 0.4em; } table.index tr:hover td:not([rowspan]), table.index tr:hover th:not([rowspan]) { color: black; color: var(--indextable-hover-text); background: #f7f8f9; background: var(--indextable-hover-bg); } /* The link in the first column in the property table (formerly a TD) */ table.index th:first-child a { font-weight: bold; } /** Outdated warning **********************************************************/ .outdated-spec { color: black; color: var(--outdatedspec-text); background-color: rgba(0,0,0,0.5); background-color: var(--outdatedspec-bg); } .outdated-warning { position: fixed; bottom: 50%; left: 0; right: 0; margin: 0 auto; width: 50%; background: maroon; background: var(--outdated-bg); color: white; color: var(--outdated-text); border-radius: 1em; box-shadow: 0 0 1em red; box-shadow: 0 0 1em var(--outdated-shadow); padding: 2em; text-align: center; z-index: 2; } .outdated-warning a { color: currentcolor; background: transparent; } .edited-rec-warning { background: darkorange; background: var(--editedrec-bg); box-shadow: 0 0 1em; } .outdated-warning button { color: var(--outdated-text); border-radius: 1em; box-shadow: 0 0 1em red; box-shadow: 0 0 1em var(--outdated-shadow); padding: 2em; text-align: center; z-index: 2; } .outdated-warning a { color: currentcolor; background: transparent; } .edited-rec-warning { background: darkorange; background: var(--editedrec-bg); box-shadow: 0 0 1em; } .outdated-warning button { position: absolute; top: 0; right:0; margin: 0; border: 0; padding: 0.25em 0.5em; background: transparent; color: white; color: var(--outdated-text); font:1em sans-serif; text-align:center; } .outdated-warning span { display: block; } .outdated-collapsed { bottom: 0; border-radius: 0; width: 100%; padding: 0; } /******************************************************************************/ /* Print */ /******************************************************************************/ @media print { /* Pages have their own margins. */ html { margin: 0; } /* Serif for print. */ body { font-family: serif; } .outdated-warning { position: absolute; border-style: solid; border-color: red; } .outdated-warning input { display: none; } } @page { margin: 1.5cm 1.1cm; } /******************************************************************************/ /* Overflow Control */ /******************************************************************************/ .figure .caption, .sidefigure .caption, figcaption { /* in case figure is overlarge, limit caption to 50em */ max-width: 50rem; margin-left: auto; margin-right: auto; } .overlarge { /* Magic to create good item positioning: "content column" is 50ems wide at max; less on smaller screens. Extra space (after ToC + content) is empty on the right. 1. When item < content column, centers item in column. 2. When content < item < available, left-aligns. 3. When item > available, fills available + scroll bar. */ display: grid; grid-template-columns: minmax(0, 50em); } .overlarge > table { /* limit preferred width of table */ max-width: 50em; margin-left: auto; margin-right: auto; } @media (min-width: 55em) { .overlarge { margin-right: calc(13px + 26.5rem - 50vw); max-width: none; } } @media screen and (min-width: 78em) { body:not(.toc-inline) .overlarge { /* 30.5em body padding 50em content area */ margin-right: calc(40em - 50vw) !important; } } @media screen and (min-width: 90em) { body:not(.toc-inline) .overlarge { /* 4em html margin 30.5em body padding 50em content area */ margin-right: calc(84.5em - 100vw) !important; } } @media not print { .overlarge { overflow-x: auto; /* See Lea Verou's explanation background-attachment: * http://lea.verou.me/2012/04/background-attachment-local/ * background: top left / 4em 100% linear-gradient(to right, #ffffff, rgba(255, 255, 255, 0)) local, top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local, top left / 1em 100% linear-gradient(to right, #c3c3c5, rgba(195, 195, 197, 0)) scroll, top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll, white; background-repeat: no-repeat; */ } } </style> <meta content="Bikeshed version a1dabb26c, updated Mon Jun 17 15:00:44 2024 -0700" name="generator"> <meta content="dark light" name="color-scheme"> <style>/* Boilerplate: style-autolinks */ .css.css, .property.property, .descriptor.descriptor { color: var(--a-normal-text); font-size: inherit; font-family: inherit; } .css::before, .property::before, .descriptor::before { content: " "; } .css::after, .property::after, .descriptor::after { content: " "; } .property, .descriptor { /* Don't wrap property and descriptor names */ white-space: nowrap; } .type { /* CSS value <type> */ font-style: italic; } pre .property::before, pre .property::after { content: ""; } [data-link-type="property"]::before, [data-link-type="propdesc"]::before, [data-link-type="descriptor"]::before, [data-link-type="value"]::before, [data-link-type="function"]::before, [data-link-type="at-rule"]::before, [data-link-type="selector"]::before, [data-link-type="maybe"]::before { content: " "; } [data-link-type="property"]::after, [data-link-type="propdesc"]::after, [data-link-type="descriptor"]::after, [data-link-type="value"]::after, [data-link-type="function"]::after, [data-link-type="at-rule"]::after, [data-link-type="selector"]::after, [data-link-type="maybe"]::after { content: " "; } [data-link-type].production::before, [data-link-type].production::after, .prod [data-link-type]::before, .prod [data-link-type]::after { content: ""; } [data-link-type=element], [data-link-type=element-attr] { font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace; font-size: .9em; } [data-link-type=element]::before { content: "<" } [data-link-type=element]::after { content: ">" } [data-link-type=biblio] { white-space: pre; } @media (prefers-color-scheme: dark) { :root { --selflink-text: black; --selflink-bg: silver; --selflink-hover-text: white; } } </style> <style>/* Boilerplate: style-colors */ /* Any --*-text not paired with a --*-bg is assumed to have a transparent bg */ :root { color-scheme: light dark; --text: black; --bg: white; --unofficial-watermark: url(https://www.w3.org/StyleSheets/TR/2016/logos/UD-watermark); --logo-bg: #1a5e9a; --logo-active-bg: #c00; --logo-text: white; --tocnav-normal-text: #707070; --tocnav-normal-bg: var(--bg); --tocnav-hover-text: var(--tocnav-normal-text); --tocnav-hover-bg: #f8f8f8; --tocnav-active-text: #c00; --tocnav-active-bg: var(--tocnav-normal-bg); --tocsidebar-text: var(--text); --tocsidebar-bg: #f7f8f9; --tocsidebar-shadow: rgba(0,0,0,.1); --tocsidebar-heading-text: hsla(203,20%,40%,.7); --toclink-text: var(--text); --toclink-underline: #3980b5; --toclink-visited-text: var(--toclink-text); --toclink-visited-underline: #054572; --heading-text: #005a9c; --hr-text: var(--text); --algo-border: #def; --del-text: red; --del-bg: transparent; --ins-text: #080; --ins-bg: transparent; --a-normal-text: #034575; --a-normal-underline: #bbb; --a-visited-text: var(--a-normal-text); --a-visited-underline: #707070; --a-hover-bg: rgba(75%, 75%, 75%, .25); --a-active-text: #c00; --a-active-underline: #c00; --blockquote-border: silver; --blockquote-bg: transparent; --blockquote-text: currentcolor; --issue-border: #e05252; --issue-bg: #fbe9e9; --issue-text: var(--text); --issueheading-text: #831616; --example-border: #e0cb52; --example-bg: #fcfaee; --example-text: var(--text); --exampleheading-text: #574b0f; --note-border: #52e052; --note-bg: #e9fbe9; --note-text: var(--text); --noteheading-text: hsl(120, 70%, 30%); --notesummary-underline: silver; --assertion-border: #aaa; --assertion-bg: #eee; --assertion-text: black; --advisement-border: orange; --advisement-bg: #fec; --advisement-text: var(--text); --advisementheading-text: #b35f00; --warning-border: red; --warning-bg: hsla(40,100%,50%,0.95); --warning-text: var(--text); --amendment-border: #330099; --amendment-bg: #F5F0FF; --amendment-text: var(--text); --amendmentheading-text: #220066; --def-border: #8ccbf2; --def-bg: #def; --def-text: var(--text); --defrow-border: #bbd7e9; --datacell-border: silver; --indexinfo-text: #707070; --indextable-hover-text: black; --indextable-hover-bg: #f7f8f9; --outdatedspec-bg: rgba(0, 0, 0, .5); --outdatedspec-text: black; --outdated-bg: maroon; --outdated-text: white; --outdated-shadow: red; --editedrec-bg: darkorange; } @media (prefers-color-scheme: dark) { :root { --text: #ddd; --bg: black; --unofficial-watermark: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='400' height='400'%3E%3Cg fill='%23100808' transform='translate(200 200) rotate(-45) translate(-200 -200)' stroke='%23100808' stroke-width='3'%3E%3Ctext x='50%25' y='220' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EUNOFFICIAL%3C/text%3E%3Ctext x='50%25' y='305' style='font: bold 70px sans-serif; text-anchor: middle; letter-spacing: 6px;'%3EDRAFT%3C/text%3E%3C/g%3E%3C/svg%3E"); --logo-bg: #1a5e9a; --logo-active-bg: #c00; --logo-text: white; --tocnav-normal-text: #999; --tocnav-normal-bg: var(--bg); --tocnav-hover-text: var(--tocnav-normal-text); --tocnav-hover-bg: #080808; --tocnav-active-text: #f44; --tocnav-active-bg: var(--tocnav-normal-bg); --tocsidebar-text: var(--text); --tocsidebar-bg: #080808; --tocsidebar-shadow: rgba(255,255,255,.1); --tocsidebar-heading-text: hsla(203,20%,40%,.7); --toclink-text: var(--text); --toclink-underline: #6af; --toclink-visited-text: var(--toclink-text); --toclink-visited-underline: #054572; --heading-text: #8af; --hr-text: var(--text); --algo-border: #456; --del-text: #f44; --del-bg: transparent; --ins-text: #4a4; --ins-bg: transparent; --a-normal-text: #6af; --a-normal-underline: #555; --a-visited-text: var(--a-normal-text); --a-visited-underline: var(--a-normal-underline); --a-hover-bg: rgba(25%, 25%, 25%, .2); --a-active-text: #f44; --a-active-underline: var(--a-active-text); --borderedblock-bg: rgba(255, 255, 255, .05); --blockquote-border: silver; --blockquote-bg: var(--borderedblock-bg); --blockquote-text: currentcolor; --issue-border: #e05252; --issue-bg: var(--borderedblock-bg); --issue-text: var(--text); --issueheading-text: hsl(0deg, 70%, 70%); --example-border: hsl(50deg, 90%, 60%); --example-bg: var(--borderedblock-bg); --example-text: var(--text); --exampleheading-text: hsl(50deg, 70%, 70%); --note-border: hsl(120deg, 100%, 35%); --note-bg: var(--borderedblock-bg); --note-text: var(--text); --noteheading-text: hsl(120, 70%, 70%); --notesummary-underline: silver; --assertion-border: #444; --assertion-bg: var(--borderedblock-bg); --assertion-text: var(--text); --advisement-border: orange; --advisement-bg: #222218; --advisement-text: var(--text); --advisementheading-text: #f84; --warning-border: red; --warning-bg: hsla(40,100%,20%,0.95); --warning-text: var(--text); --amendment-border: #330099; --amendment-bg: #080010; --amendment-text: var(--text); --amendmentheading-text: #cc00ff; --def-border: #8ccbf2; --def-bg: #080818; --def-text: var(--text); --defrow-border: #136; --datacell-border: silver; --indexinfo-text: #aaa; --indextable-hover-text: var(--text); --indextable-hover-bg: #181818; --outdatedspec-bg: rgba(255, 255, 255, .5); --outdatedspec-text: black; --outdated-bg: maroon; --outdated-text: white; --outdated-shadow: red; --editedrec-bg: darkorange; } /* In case a transparent-bg image doesn't expect to be on a dark bg, which is quite common in practice... */ img { background: white; } } </style> <style>/* Boilerplate: style-counters */ body { counter-reset: example figure issue; } .issue { counter-increment: issue; } .issue:not(.no-marker)::before { content: "Issue " counter(issue); } .example { counter-increment: example; } .example:not(.no-marker)::before { content: "Example " counter(example); } .invalid.example:not(.no-marker)::before, .illegal.example:not(.no-marker)::before { content: "Invalid Example" counter(example); } figcaption { counter-increment: figure; } figcaption:not(.no-marker)::before { content: "Figure " counter(figure) " "; } </style> <style>/* Boilerplate: style-issues */ a[href].issue-return { float: right; float: inline-end; color: var(--issueheading-text); font-weight: bold; text-decoration: none; } </style> <style>/* Boilerplate: style-md-lists */ /* This is a weird hack for me not yet following the commonmark spec regarding paragraph and lists. */ [data-md] > :first-child { margin-top: 0; } [data-md] > :last-child { margin-bottom: 0; } </style> <style>/* Boilerplate: style-selflinks */ :root { --selflink-text: white; --selflink-bg: gray; --selflink-hover-text: black; } .heading, .issue, .note, .example, li, dt { position: relative; } a.self-link { position: absolute; top: 0; left: calc(-1 * (3.5rem - 26px)); width: calc(3.5rem - 26px); height: 2em; text-align: center; border: none; transition: opacity .2s; opacity: .5; } a.self-link:hover { opacity: 1; } .heading > a.self-link { font-size: 83%; } .example > a.self-link, .note > a.self-link, .issue > a.self-link { /* These blocks are overflow:auto, so positioning outside doesn't work. */ left: auto; right: 0; } li > a.self-link { left: calc(-1 * (3.5rem - 26px) - 2em); } dfn > a.self-link { top: auto; left: auto; opacity: 0; width: 1.5em; height: 1.5em; background: var(--selflink-bg); color: var(--selflink-text); font-style: normal; transition: opacity .2s, background-color .2s, color .2s; } dfn:hover > a.self-link { opacity: 1; } dfn > a.self-link:hover { color: var(--selflink-hover-text); } a.self-link::before { content: "�"; } .heading > a.self-link::before { content: "�"; } dfn > a.self-link::before { content: "#"; } </style> <style>/* Boilerplate: style-syntax-highlighting */ code.highlight { padding: .1em; border-radius: .3em; } pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; } .highlight:not(.idl) { background: rgba(0, 0, 0, .03); } c-[a] { color: #990055 } /* Keyword.Declaration */ c-[b] { color: #990055 } /* Keyword.Type */ c-[c] { color: #708090 } /* Comment */ c-[d] { color: #708090 } /* Comment.Multiline */ c-[e] { color: #0077aa } /* Name.Attribute */ c-[f] { color: #669900 } /* Name.Tag */ c-[g] { color: #222222 } /* Name.Variable */ c-[k] { color: #990055 } /* Keyword */ c-[l] { color: #000000 } /* Literal */ c-[m] { color: #000000 } /* Literal.Number */ c-[n] { color: #0077aa } /* Name */ c-[o] { color: #999999 } /* Operator */ c-[p] { color: #999999 } /* Punctuation */ c-[s] { color: #a67f59 } /* Literal.String */ c-[t] { color: #a67f59 } /* Literal.String.Single */ c-[u] { color: #a67f59 } /* Literal.String.Double */ c-[cp] { color: #708090 } /* Comment.Preproc */ c-[c1] { color: #708090 } /* Comment.Single */ c-[cs] { color: #708090 } /* Comment.Special */ c-[kc] { color: #990055 } /* Keyword.Constant */ c-[kn] { color: #990055 } /* Keyword.Namespace */ c-[kp] { color: #990055 } /* Keyword.Pseudo */ c-[kr] { color: #990055 } /* Keyword.Reserved */ c-[ld] { color: #000000 } /* Literal.Date */ c-[nc] { color: #0077aa } /* Name.Class */ c-[no] { color: #0077aa } /* Name.Constant */ c-[nd] { color: #0077aa } /* Name.Decorator */ c-[ni] { color: #0077aa } /* Name.Entity */ c-[ne] { color: #0077aa } /* Name.Exception */ c-[nf] { color: #0077aa } /* Name.Function */ c-[nl] { color: #0077aa } /* Name.Label */ c-[nn] { color: #0077aa } /* Name.Namespace */ c-[py] { color: #0077aa } /* Name.Property */ c-[ow] { color: #999999 } /* Operator.Word */ c-[mb] { color: #000000 } /* Literal.Number.Bin */ c-[mf] { color: #000000 } /* Literal.Number.Float */ c-[mh] { color: #000000 } /* Literal.Number.Hex */ c-[mi] { color: #000000 } /* Literal.Number.Integer */ c-[mo] { color: #000000 } /* Literal.Number.Oct */ c-[sb] { color: #a67f59 } /* Literal.String.Backtick */ c-[sc] { color: #a67f59 } /* Literal.String.Char */ c-[sd] { color: #a67f59 } /* Literal.String.Doc */ c-[se] { color: #a67f59 } /* Literal.String.Escape */ c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */ c-[si] { color: #a67f59 } /* Literal.String.Interpol */ c-[sx] { color: #a67f59 } /* Literal.String.Other */ c-[sr] { color: #a67f59 } /* Literal.String.Regex */ c-[ss] { color: #a67f59 } /* Literal.String.Symbol */ c-[vc] { color: #0077aa } /* Name.Variable.Class */ c-[vg] { color: #0077aa } /* Name.Variable.Global */ c-[vi] { color: #0077aa } /* Name.Variable.Instance */ c-[il] { color: #000000 } /* Literal.Number.Integer.Long */ @media (prefers-color-scheme: dark) { .highlight:not(.idl) { background: rgba(255, 255, 255, .05); } c-[a] { color: #d33682 } /* Keyword.Declaration */ c-[b] { color: #d33682 } /* Keyword.Type */ c-[c] { color: #2aa198 } /* Comment */ c-[d] { color: #2aa198 } /* Comment.Multiline */ c-[e] { color: #268bd2 } /* Name.Attribute */ c-[f] { color: #b58900 } /* Name.Tag */ c-[g] { color: #cb4b16 } /* Name.Variable */ c-[k] { color: #d33682 } /* Keyword */ c-[l] { color: #657b83 } /* Literal */ c-[m] { color: #657b83 } /* Literal.Number */ c-[n] { color: #268bd2 } /* Name */ c-[o] { color: #657b83 } /* Operator */ c-[p] { color: #657b83 } /* Punctuation */ c-[s] { color: #6c71c4 } /* Literal.String */ c-[t] { color: #6c71c4 } /* Literal.String.Single */ c-[u] { color: #6c71c4 } /* Literal.String.Double */ c-[ch] { color: #2aa198 } /* Comment.Hashbang */ c-[cp] { color: #2aa198 } /* Comment.Preproc */ c-[cpf] { color: #2aa198 } /* Comment.PreprocFile */ c-[c1] { color: #2aa198 } /* Comment.Single */ c-[cs] { color: #2aa198 } /* Comment.Special */ c-[kc] { color: #d33682 } /* Keyword.Constant */ c-[kn] { color: #d33682 } /* Keyword.Namespace */ c-[kp] { color: #d33682 } /* Keyword.Pseudo */ c-[kr] { color: #d33682 } /* Keyword.Reserved */ c-[ld] { color: #657b83 } /* Literal.Date */ c-[nc] { color: #268bd2 } /* Name.Class */ c-[no] { color: #268bd2 } /* Name.Constant */ c-[nd] { color: #268bd2 } /* Name.Decorator */ c-[ni] { color: #268bd2 } /* Name.Entity */ c-[ne] { color: #268bd2 } /* Name.Exception */ c-[nf] { color: #268bd2 } /* Name.Function */ c-[nl] { color: #268bd2 } /* Name.Label */ c-[nn] { color: #268bd2 } /* Name.Namespace */ c-[py] { color: #268bd2 } /* Name.Property */ c-[ow] { color: #657b83 } /* Operator.Word */ c-[mb] { color: #657b83 } /* Literal.Number.Bin */ c-[mf] { color: #657b83 } /* Literal.Number.Float */ c-[mh] { color: #657b83 } /* Literal.Number.Hex */ c-[mi] { color: #657b83 } /* Literal.Number.Integer */ c-[mo] { color: #657b83 } /* Literal.Number.Oct */ c-[sa] { color: #6c71c4 } /* Literal.String.Affix */ c-[sb] { color: #6c71c4 } /* Literal.String.Backtick */ c-[sc] { color: #6c71c4 } /* Literal.String.Char */ c-[dl] { color: #6c71c4 } /* Literal.String.Delimiter */ c-[sd] { color: #6c71c4 } /* Literal.String.Doc */ c-[se] { color: #6c71c4 } /* Literal.String.Escape */ c-[sh] { color: #6c71c4 } /* Literal.String.Heredoc */ c-[si] { color: #6c71c4 } /* Literal.String.Interpol */ c-[sx] { color: #6c71c4 } /* Literal.String.Other */ c-[sr] { color: #6c71c4 } /* Literal.String.Regex */ c-[ss] { color: #6c71c4 } /* Literal.String.Symbol */ c-[fm] { color: #268bd2 } /* Name.Function.Magic */ c-[vc] { color: #cb4b16 } /* Name.Variable.Class */ c-[vg] { color: #cb4b16 } /* Name.Variable.Global */ c-[vi] { color: #cb4b16 } /* Name.Variable.Instance */ c-[vm] { color: #cb4b16 } /* Name.Variable.Magic */ c-[il] { color: #657b83 } /* Literal.Number.Integer.Long */ } </style> <body class="h-entry"> <div class="head"> <p data-fill-with="logo"><a href="https://www.dashif.org/"> <img src="Images/DASH-IF.png"> </a> </p> <h1 class="p-name no-ref" id="title">DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX)</h1> <h2 class="no-num no-toc no-ref heading settled" id="profile-and-date"><span class="content">Commit Snapshot, <time class="dt-updated" datetime="2023-07-12">12 July 2023</time></span></h2> <div data-fill-with="spec-metadata"> <dl> <dt>Issue Tracking: <dd><a href="https://github.com/Dash-Industry-Forum/CPIX/issues">GitHub</a> <dt class="editor">Editor: <dd class="editor p-author h-card vcard"><span class="p-name fn">DASH Industry Forum</span> </dl> </div> <div data-fill-with="warning"></div> <hr title="Separator for header"> </div> <div data-fill-with="at-risk"></div> <nav data-fill-with="table-of-contents" id="toc"> <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2> <ol class="toc" role="directory"> <li><a href="#scope"><span class="secno">1</span> <span class="content">Scope</span></a> <li><a href="#disclaimer"><span class="secno">2</span> <span class="content">Disclaimer</span></a> <li><a href="#norme"><span class="secno">3</span> <span class="content">Normative Language</span></a> <li><a href="#intro"><span class="secno">4</span> <span class="content">Introduction</span></a> <li><a href="#terms"><span class="secno">5</span> <span class="content">Definition of Terms</span></a> <li> <a href="#usecases"><span class="secno">6</span> <span class="content">Use Cases and Requirements</span></a> <ol class="toc"> <li><a href="#usecases-intro"><span class="secno">6.1</span> <span class="content">Introduction</span></a> <li><a href="#usecases-architecture"><span class="secno">6.2</span> <span class="content">Overview of the End to End Architecture</span></a> <li> <a href="#usecases-packaging"><span class="secno">6.3</span> <span class="content">Use Cases for the Preparation of Content</span></a> <ol class="toc"> <li><a href="#usecases-packaging-intro"><span class="secno">6.3.1</span> <span class="content">Introduction</span></a> <li><a href="#usecases-packaging-ondemand"><span class="secno">6.3.2</span> <span class="content">On-Demand Content</span></a> <li><a href="#usecases-packaging-live"><span class="secno">6.3.3</span> <span class="content">Live Content</span></a> <li><a href="#usecases-packaging-catchup"><span class="secno">6.3.4</span> <span class="content">Catch-up</span></a> </ol> <li> <a href="#usecases-exchange"><span class="secno">6.4</span> <span class="content">Exchange over an Interface</span></a> <ol class="toc"> <li><a href="#usecase-exchange-intro"><span class="secno">6.4.1</span> <span class="content">Introduction</span></a> <li><a href="#usecases-exchange-deliverytoone"><span class="secno">6.4.2</span> <span class="content">Content Key Delivery to One Entity</span></a> <li><a href="#usecases-exchange-securedeliverytomany"><span class="secno">6.4.3</span> <span class="content">Secure Content Key Delivery to Several Entities</span></a> <li> <a href="#usecases-exchange-usagerules"><span class="secno">6.4.4</span> <span class="content">Content Key Delivery with Usage Rules</span></a> <ol class="toc"> <li><a href="#usecases-exchange-usagerules-intro"><span class="secno">6.4.4.1</span> <span class="content">Introduction</span></a> <li><a href="#usecases-exchange-usagerules-labelfilter"><span class="secno">6.4.4.2</span> <span class="content">Label Filter</span></a> <li><a href="#usecases-exchange-usagerules-periodfilter"><span class="secno">6.4.4.3</span> <span class="content">Key Period Filter</span></a> <li><a href="#usecases-exchange-usagerules-policyfilters"><span class="secno">6.4.4.4</span> <span class="content">Policy-based Filters</span></a> </ol> <li><a href="#usecases-exchange-drmsignaling"><span class="secno">6.4.5</span> <span class="content">Content Key Delivery with DRM Signaling</span></a> <li><a href="#usecases-exchange-incrementalauthoring"><span class="secno">6.4.6</span> <span class="content">Incremental Update and Extension of the Document</span></a> <li><a href="#usecases-exchange-multipleassets"><span class="secno">6.4.7</span> <span class="content">Multiple Content Keys Delivery for Multiples Assets</span></a> <li><a href="#usecases-exchange-hierarchydelivery"><span class="secno">6.4.8</span> <span class="content">Content Key Hierarchy Delivery for Content Packaging</span></a> <li><a href="#usecases-exchange-rootkeydelivery"><span class="secno">6.4.9</span> <span class="content">Root Key Delivery for License Server Operation</span></a> </ol> <li> <a href="#usecases-workflows"><span class="secno">6.5</span> <span class="content">Workflow Examples</span></a> <ol class="toc"> <li> <a href="#usecases-workflows-encryptorandproducer"><span class="secno">6.5.1</span> <span class="content">Encryptor Producer and Encryptor Consumer</span></a> <ol class="toc"> <li><a href="#usecases-workflows-encryptorandproducer-intro"><span class="secno">6.5.1.1</span> <span class="content">Introduction</span></a> <li><a href="#usecases-workflows-encryptorandproducer-encryptorproducer"><span class="secno">6.5.1.2</span> <span class="content">Encryptor Producer</span></a> <li><a href="#usecases-workflows-encryptorandproducer-encryptorconsumer"><span class="secno">6.5.1.3</span> <span class="content">Encryptor Consumer</span></a> </ol> <li><a href="#usecases-workflows-multipleproducers"><span class="secno">6.5.2</span> <span class="content">Multiple Producers</span></a> </ol> </ol> <li> <a href="#schema"><span class="secno">7</span> <span class="content">XSD Schema Definition</span></a> <ol class="toc"> <li><a href="#schema-intro"><span class="secno">7.1</span> <span class="content">Introduction</span></a> <li><a href="#schema-requirements"><span class="secno">7.2</span> <span class="content">Requirements</span></a> <li><a href="#schema-structure"><span class="secno">7.3</span> <span class="content">Structure Overview</span></a> <li> <a href="#schema-datamodel"><span class="secno">7.4</span> <span class="content">Hierarchical Data Model</span></a> <ol class="toc"> <li><a href="#schema-datamodel-intro"><span class="secno">7.4.1</span> <span class="content">Introduction</span></a> <li><a href="#schema-datamodel-cpix"><span class="secno">7.4.2</span> <span class="content"><code class="highlight">CPIX</code> Element</span></a> <li><a href="#schema-datamodel-deliverydatalist"><span class="secno">7.4.3</span> <span class="content"><code class="highlight">DeliveryDataList</code> Element</span></a> <li><a href="#schema-datamodel-deliverydata"><span class="secno">7.4.4</span> <span class="content"><code class="highlight">DeliveryData</code> Element</span></a> <li><a href="#schema-datamodel-documentkey"><span class="secno">7.4.5</span> <span class="content"><code class="highlight">DocumentKey</code> Element</span></a> <li><a href="#schema-datamodel-contentkeylist"><span class="secno">7.4.6</span> <span class="content"><code class="highlight">ContentKeyList</code> Element</span></a> <li><a href="#schema-datamodel-contentkey"><span class="secno">7.4.7</span> <span class="content"><code class="highlight">ContentKey</code> Element</span></a> <li><a href="#schema-datamodel-HDCPdata"><span class="secno">7.4.8</span> <span class="content"><code class="highlight">HDCPData</code> Element</span></a> <li><a href="#schema-datamodel-drmsystemlist"><span class="secno">7.4.9</span> <span class="content"><code class="highlight">DRMSystemList</code> Element</span></a> <li><a href="#schema-datamodel-drmsystem"><span class="secno">7.4.10</span> <span class="content"><code class="highlight">DRMSystem</code> Element</span></a> <li><a href="#schema-datamodel-contentprotectiondata"><span class="secno">7.4.11</span> <span class="content"><code class="highlight">ContentProtectionData</code> Element</span></a> <li><a href="#schema-datamodel-HLSsignalingdata"><span class="secno">7.4.12</span> <span class="content"><code class="highlight">HLSSignalingData</code> Element</span></a> <li><a href="#schema-datamodel-contentkeyperiodlist"><span class="secno">7.4.13</span> <span class="content"><code class="highlight">ContentKeyPeriodList</code> Element</span></a> <li><a href="#schema-datamodel-contentkeyperiod"><span class="secno">7.4.14</span> <span class="content"><code class="highlight">ContentKeyPeriod</code> Element</span></a> <li><a href="#schema-datamodel-contentkeyusagerulelist"><span class="secno">7.4.15</span> <span class="content"><code class="highlight">ContentKeyUsageRuleList</code> Element</span></a> <li><a href="#schema-datamodel-contentkeyusagerule"><span class="secno">7.4.16</span> <span class="content"><code class="highlight">ContentKeyUsageRule</code> Element</span></a> <li> <a href="#schema-datamodel-usagerulefilter"><span class="secno">7.4.17</span> <span class="content">Usage Rules Filters</span></a> <ol class="toc"> <li><a href="#schema-datamodel-usagerulefilter-intro"><span class="secno">7.4.17.1</span> <span class="content">Introduction</span></a> <li><a href="#schema-datamodel-usagerulefilter-keyperiodfilter"><span class="secno">7.4.17.2</span> <span class="content"><code class="highlight">KeyPeriodFilter</code> Element</span></a> <li><a href="#schema-datamodel-usagerulefilter-labelfilter"><span class="secno">7.4.17.3</span> <span class="content"><code class="highlight">LabelFilter</code> Element</span></a> <li><a href="#schema-datamodel-usagerulefilter-videofilter"><span class="secno">7.4.17.4</span> <span class="content"><code class="highlight">VideoFilter</code> Element</span></a> <li><a href="#schema-datamodel-usagerulefilter-audiofilter"><span class="secno">7.4.17.5</span> <span class="content"><code class="highlight">AudioFilter</code> Element</span></a> <li><a href="#schema-datamodel-usagerulefilter-bitratefilter"><span class="secno">7.4.17.6</span> <span class="content"><code class="highlight">BitrateFilter</code> Element</span></a> </ol> <li><a href="#schema-datamodel-updatehistoryitemlist"><span class="secno">7.4.18</span> <span class="content"><code class="highlight">UpdateHistoryItemList</code> Element</span></a> <li><a href="#schema-datamodel-updatehistoryitem"><span class="secno">7.4.19</span> <span class="content"><code class="highlight">UpdateHistoryItem</code> Element</span></a> </ol> </ol> <li> <a href="#keys"><span class="secno">8</span> <span class="content">Key Management</span></a> <ol class="toc"> <li> <a href="#keys-enc"><span class="secno">8.1</span> <span class="content">Key Encryption and Authentication in the CPIX Document</span></a> <ol class="toc"> <li><a href="#keys-enc-intro"><span class="secno">8.1.1</span> <span class="content">Introduction</span></a> <li><a href="#keys-enc-keytypes"><span class="secno">8.1.2</span> <span class="content">Encryption</span></a> <li><a href="#keys-enc-mac"><span class="secno">8.1.3</span> <span class="content">Authenticated Encryption</span></a> <li><a href="#keys-enc-signatures"><span class="secno">8.1.4</span> <span class="content">Digital Signature</span></a> <li><a href="#keys-enc-algorithms"><span class="secno">8.1.5</span> <span class="content">Mandatory Algorithms</span></a> </ol> <li><a href="#keys-rotation"><span class="secno">8.2</span> <span class="content">Key Rotation Support</span></a> <li><a href="#keys-encryptionScheme"><span class="secno">8.3</span> <span class="content">Content Keys with Several Protection Encryption Schemes</span></a> </ol> <li><a href="#best-practices"><span class="secno">9</span> <span class="content">CPIX Documents Best Practices</span></a> <li><a href="#abbreviations"><span class="secno">10</span> <span class="content">Abbreviations</span></a> <li> <a href="#references"><span class="secno"></span> <span class="content">References</span></a> <ol class="toc"> <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a> </ol> </ol> </nav> <main> <table class="def" style="font-family:&quot;sans-serif&quot;" valign="top"> <tbody> <tr> <td colspan="6"><b>Candidate Technical Specification</b> <tr> <td colspan="2"><b>DASH-IF CTS</b> <td><b>Part XX</b> <td><b>rev 0</b> <td colspan="2"><b> Current version 2.4</b> <tr> <td><b>Status:</b> <td>Draft <td>Internal Review <td>Community Review <td>IOP Review <td>IPR Review <tr> <td><b>Title:</b> <td colspan="5">DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX) <tr> <td><b>Source:</b> <td colspan="5">DASH-IF Interoperability Working Group,<br>DASH-IF Content Protection and Security TF <tr> <td><b>Supporting<br>Compagnies:</b> <td colspan="5"> <tr> <td><b>Category:</b> <td colspan="3"><b> Candidate Technical Specification</b> <td colspan="2"> <b>Date:</b> 2023-07-12 <tr> <td><b>Abstract:</b> <td colspan="5">This document defines a container allowing the exchange between entities of content protection information typically made of keys used for encrypting content and any associated DRM specific information.<br>There may be one or several keys and these keys may be protected by one or several DRMs, hence there may be one or several DRM specific information. There is no assumption on the entities exchanging this information but it is not expected that a client device will use this exchange format. The goal is to allow entities involved in the content preparation workflow to get the content protection information so that, for example a DASH MPD can be generated with all content protection information. Because the defined container is not made for a specifically defined content preparation workflow but is generic, conformance is not considered to be a critical part of CPIX. As a consequence, no conformance is defined for this specification. <tr> <td><b>Disclaimer:</b> <td colspan="5">This document is a candidate Technical Specification. DASH-IF is expecting to publish this initially, but to submit the specification to a formal specification organization. The primary choice is ETSI, for which DASH-IF has a PAS agreement.<br>This document is approved by DASH-IF IOP will be sent for IPR Review as well as to ETSI for publication. <tr> <td><b>Expected<br>Publication:</b> <td colspan="5"> <tr> <td><b>Other<br>Comments:</b> <td colspan="5"> </table> <h2 class="heading settled" data-level="1" id="scope"><span class="secno">1. </span><span class="content">Scope</span><a class="self-link" href="#scope"></a></h2> <p>The scope of this document is to define a Content Protection Information Exchange Format (CPIX). A CPIX document contains keys and DRM information used for encrypting and protecting content and can be used for exchanging this information among entities needing it in many possibly different workflows for preparing, for example, DASH or HLS content. The CPIX document itself can be encrypted, signed and authenticated so that its receivers can be sure that its confidentiality, source and integrity are also protected.</p> <p>This specification describes version 2.4 of the CPIX document format.</p> <p>Detailed changes with respect to version 2.3.1 are tracked on <a href="https://github.com/Dash-Industry-Forum/CPIX/issues">GitHub</a>. Highlighted changes are:</p> <ul> <li data-md> <p>Added the option to encrypt Content Keys with different Document Keys, see clauses <a href="#schema-datamodel-deliverydatalist">�/ 7.4.3 DeliveryDataList Element</a> and <a href="#keys-enc-keytypes">�/ 8.1.2 Encryption</a></p> <li data-md> <p>Added the option to have in one document with Content Keys for different content, allowing the bulk transfer of content keys information in one document, hence adding a <code class="highlight">@contentId</code>under the <code class="highlight">ContentKey</code> element, see clause <a href="#usecases-exchange-multipleassets">�/ 6.4.7 Multiple Content Keys Delivery for Multiples Assets</a> and <a href="#schema-datamodel-contentkey">�/ 7.4.7 ContentKey Element</a></p> <li data-md> <p>Added HDCP information attached to the Content Key to be inserted in both HLS playlist and DASH MPD, see clause <a href="#schema-datamodel-HDCPdata">�/ 7.4.8 HDCPData Element</a></p> <li data-md> <p>Added expected DRM robustness information to be inserted in both HLS playlist and DASH MPD, see clause <a href="#schema-datamodel-drmsystem">�/ 7.4.10 DRMSystem Element</a> and <a href="#schema-datamodel-contentprotectiondata">�/ 7.4.11 ContentProtectionData Element</a></p> <li data-md> <p>Simplified the <code class="highlight">ContentKey</code> element by removing all non-used element inherited from the PSCK model, see clause <a href="#schema-datamodel-contentkey">�/ 7.4.7 ContentKey Element</a></p> <li data-md> <p>Updated the HLS terminology to <code class="highlight">multiVariant</code>, see clause <a href="#schema-datamodel-HLSsignalingdata">�/ 7.4.12 HLSSignalingData Element</a></p> <li data-md> <p>Removed the signaling for HDS and the deprecated <code class="highlight">URIExtXKey</code> for HLS, see clause <a href="#schema-datamodel-drmsystem">�/ 7.4.10 DRMSystem Element</a></p> <li data-md> <p>Updated references</p> </ul> <p>Detailed changes with respect to version 2.3 are tracked on <a href="https://github.com/Dash-Industry-Forum/CPIX/issues">GitHub</a>. Highlighted changes are:</p> <ul> <li data-md> <p>Clarified that key ids shall be UUID as described in <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a> (added a constraint)</p> <li data-md> <p>Corrected a bug on <code class="highlight">@periodId</code> that shall be a XS:REFID, see clause <a href="#schema-datamodel-usagerulefilter-keyperiodfilter">�/ 7.4.17.2 KeyPeriodFilter Element</a></p> <li data-md> <p>Clarification on the <code class="highlight">@explicitIV</code> attribute under the <code class="highlight">ContentKey</code> element encoding, see clause <a href="#schema-datamodel-contentkey">�/ 7.4.7 ContentKey Element</a></p> <li data-md> <p>Taking into account the scenario described in Clause 9 of <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a> for key rotation, clarification for the <code class="highlight">PSSH</code> and <code class="highlight">ContentProtectionData</code> content under <code class="highlight">DRMSystem</code>. A clause is also added on this topic. See clause <a href="#schema-datamodel-drmsystem">�/ 7.4.10 DRMSystem Element</a> and <a href="#keys-rotation">�/ 8.2 Key Rotation Support</a></p> <li data-md> <p>Clean-up the Use Cases and Requirements clause (removed the electronic sell through use case)</p> <li data-md> <p>Addition of the <code class="highlight">@version</code> attribute under the <code class="highlight">CPIX</code> element, see clause <a href="#schema-datamodel-cpix">�/ 7.4.2 CPIX Element</a></p> <li data-md> <p>Addition of a clause on using the same content key with different encryption schemes, see clause <a href="#keys-encryptionScheme">�/ 8.3 Content Keys with Several Protection Encryption Schemes</a></p> <li data-md> <p>Updated references</p> </ul> <h2 class="heading settled" data-level="2" id="disclaimer"><span class="secno">2. </span><span class="content">Disclaimer</span><a class="self-link" href="#disclaimer"></a></h2> <p>This is a document made available by DASH-IF. The technology embodied in this document may involve the use of intellectual property rights, including patents and patent applications owned or controlled by any of the authors or developers of this document. No patent license, either implied or express, is granted to you by this document. DASH-IF has made no search or investigation for such rights and DASH-IF disclaims any duty to do so. The rights and obligations which apply to DASH-IF documents, as such rights and obligations are set forth and defined in the DASH-IF Bylaws and IPR Policy including, but not limited to, patent and other intellectual property license rights and obligations. A copy of the DASH-IF Bylaws and IPR Policy can be obtained at https://dashif.org/.</p> <p>The material contained herein is provided on an AS IS basis and to the maximum extent permitted by applicable law, this material is provided AS IS, and the authors and developers of this material and DASH-IF hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of workmanlike effort, and of lack of negligence.</p> <p>In addition, this document may include references to documents and/or technologies controlled by third parties.Those third party documents and technologies may be subject to third party rules and licensing terms. No intellectual property license, either implied or express, to any third party material is granted to you by this document or DASH-IF. DASH-IF makes no any warranty whatsoever for such third party material.</p> <h2 class="heading settled" data-level="3" id="norme"><span class="secno">3. </span><span class="content">Normative Language</span><a class="self-link" href="#norme"></a></h2> <p>In the present document <strong>shall</strong>, <strong>shall not</strong>, <strong>should</strong>, <strong>should not</strong>, <strong>may</strong>, <strong>need not</strong>, <strong>will</strong>, <strong>will not</strong>, <strong>can</strong> and <strong>cannot</strong> are to be interpreted as described in clause 3.2 of the <a href="https://portal.etsi.org/Services/editHelp!/Howtostart/ETSIDraftingRules.aspx">ETSI Drafting Rules</a> (Verbal forms for the expression of provisions). <strong>must</strong> and <strong>must not</strong> are NOT allowed in deliverables except when used in direct citation.</p> <h2 class="heading settled" data-level="4" id="intro"><span class="secno">4. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2> <p>This document defines a container allowing the exchange between entities of content protection information typically made of keys used for encrypting content and any associated DRM specific information. There may be one or several keys and these keys may be protected by one or several DRMs, hence there may be one or several DRM specific information. There is no assumption on the entities exchanging this information but it is not expected that a client device will use this exchange format. The goal is to allow entities involved in the content preparation workflow to get the content protection information so that, for example a DASH MPD can be generated with all content protection information.</p> <p>Because the defined container is not made for a specifically defined content preparation workflow but is generic, conformance is not considered to be a critical part of CPIX. As a consequence, no conformance is defined for this specification.</p> <h2 class="heading settled" data-level="5" id="terms"><span class="secno">5. </span><span class="content">Definition of Terms</span><a class="self-link" href="#terms"></a></h2> <dl> <dt data-md>Content <dd data-md> <p>One or more audio-visual elementary streams and the associated MPD if in DASH format.</p> <dt data-md>Content Key <dd data-md> <p>A cryptographic key used for encrypting part of the Content.</p> <dt data-md>Content Key Context <dd data-md> <p>The portion of a media stream which is encrypted with a specific Content Key.</p> <dt data-md>Content Protection <dd data-md> <p>The mechanism ensuring that only authorized devices get access to Content.</p> <dt data-md>Document Key <dd data-md> <p>A cryptographic key used for encrypting the Content Key(s) in the CPIX document.</p> <dt data-md>DRM Signaling <dd data-md> <p>The DRM specific information to be added in Content for proper operation of the DRM system when authorizing a device for this Content. It is made of proprietary information for licensing and key retrieval.</p> <dt data-md>PSSH <dd data-md> <p>Protection System Specific Header box that is part of an ISOBMFF file. This box contains DRM Signaling.</p> </dl> <h2 class="heading settled" data-level="6" id="usecases"><span class="secno">6. </span><span class="content">Use Cases and Requirements</span><a class="self-link" href="#usecases"></a></h2> <h3 class="heading settled" data-level="6.1" id="usecases-intro"><span class="secno">6.1. </span><span class="content">Introduction</span><a class="self-link" href="#usecases-intro"></a></h3> <p>Content Keys and DRM Signaling, a.k.a. content protection information need to be created and exchanged between some system entities when preparing Content. The flows of information are of very different nature depending on where Content Keys are created and also depending on the type of Content that can be either On-Demand or Live.</p> <p>This clause presents different use cases where such exchanges are required. <a href="#usecases-architecture">�/ 6.2 Overview of the End to End Architecture</a> is an overview of the general context in which exchange of content protection information is happening, <a href="#usecases-packaging">�/ 6.3 Use Cases for the Preparation of Content</a> describes some workflows for content creation and <a href="#usecases-exchange">�/ 6.4 Exchange over an Interface</a> goes in the details of how content protection information can be exchanged over an interface between two entities.</p> <h3 class="heading settled" data-level="6.2" id="usecases-architecture"><span class="secno">6.2. </span><span class="content">Overview of the End to End Architecture</span><a class="self-link" href="#usecases-architecture"></a></h3> <p>This clause gives a general overview of the context in which content protection information need to be exchanged between entities in the backend. It completes clause 4 of <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a> by putting more emphasis on the backend aspects.</p> <p>This clause takes DASH content as an example for providing more specific and clear understanding, but this can be generalized to other streaming formats, such as HLS <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a>.</p> <figure> <img src="Images/Architecture.png"> <figcaption>Logical roles that exchange DRM information and media.</figcaption> </figure> <p>The figure above shows logical entities that may send or receive content protection information such as content keys, asset identifiers, licenses, and DRM signaling (license acquisition information for example). A physical entity may combine multiple logical roles, and the point of origin for information, such as content keys and asset identifiers, can differ; so various information flows are possible. This is an example of how the roles are distributed to facilitate the description of workflow and use cases. Alternative roles and functions can be applied to create conformant content. The different roles are:</p> <dl> <dt data-md>Content Provider <dd data-md> <p>A publisher who provides the rights and rules for delivering protected media, also possibly source media (mezzanine format, for transcoding), asset identifiers, key identifiers (KID), content key values, encoding instructions, and content description metadata.</p> <dt data-md>Encoder <dd data-md> <p>A service provider who encodes media in a specified set of formats with different bitrates and resolutions etc., possibly determined by the publisher.</p> <dt data-md>Packager / Encryptor <dd data-md> <p>A service provider who encrypts and packages media, inserting DRM Signaling and metadata into the media files. In the case of DASH packaging, this consists of adding the default_KID in the file header <code class="highlight">tenc</code> box, initialization vectors (IV) and subsample byte ranges in track fragments indexed by <code class="highlight">saio</code> and <code class="highlight">saiz</code> boxes, and possibly one or more <code class="highlight">pssh</code> boxes containing license acquisition information (from the DRM Service). Tracks that are partially encrypted or encrypted with multiple keys require sample to group boxes and sample group description boxes in each track fragment to associate different KIDs to groups of samples. The Packager could originate values for KIDs, Content Keys, encryption layout, etc., then send that information to other entities that need it, including the DRM Service, and probably the Content Provider. However, the Packager could receive that information from a different point of origin, such as the Content Provider or DRM Service.</p> <dt data-md>Manifest Creator <dd data-md> <p>A service provider which generates the media manifests which group the various media files into a coherent presentation. These manifest files may contain DRM signaling information. For DASH, the MPD Creator is assumed to create one or more types of DASH MPD files and provide indexing of segments and/or <code class="highlight">sidx</code> indexes for download so that players can byte range index subsegments. The MPD shall include descriptors for Common Encryption and DRM systems and should include identification of the <code class="highlight">@default_KID</code> for each <code class="highlight">AdaptationSet</code> element, and sufficient information in <code class="highlight">ContentProtection</code> elements to acquire a DRM license. The <code class="highlight">@default_KID</code> is available from the Packager and any other role that created it, and the DRM signaling is available from the DRM Service.</p> <dt data-md>DRM Client <dd data-md> <p>It gets information from different sources: media manifest files, media files, and DRM licenses.</p> <dt data-md>DRM Service <dd data-md> <p>The DRM Service creates licenses containing a protected Content Key that can only be decrypted by a trusted DRM Client. It needs to know the <code class="highlight">@default_KID</code> and DRM systemID and possibly other information like asset ID in order to create and download one or more licenses required for a <code class="highlight">Presentation</code> on a particular device. Each DRM system has different license acquisition information, a slightly different license acquisition protocol, and a different license format with different playback rules, output rules, revocation and renewal system, etc. For DASH, the DRM Service typically shall supply the Packager license acquisition information for each <code class="highlight">ContentProtection</code> element or <code class="highlight">pssh</code> box, respectively. The DRM Service may also provide logic to manage key rotation, DRM domain management, revocation and renewal and other Content Protection related features.</p> </dl> <h3 class="heading settled" data-level="6.3" id="usecases-packaging"><span class="secno">6.3. </span><span class="content">Use Cases for the Preparation of Content</span><a class="self-link" href="#usecases-packaging"></a></h3> <h4 class="heading settled" data-level="6.3.1" id="usecases-packaging-intro"><span class="secno">6.3.1. </span><span class="content">Introduction</span><a class="self-link" href="#usecases-packaging-intro"></a></h4> <p>This clause describes some workflows for content preparation where content protection information is exchanged between or carried through some entities.</p> <p>As for the previous clause, this clause takes DASH content as an example for providing more specific and clear understanding, but this can be generalized to other streaming formats, such as HLS.</p> <h4 class="heading settled" data-level="6.3.2" id="usecases-packaging-ondemand"><span class="secno">6.3.2. </span><span class="content">On-Demand Content</span><a class="self-link" href="#usecases-packaging-ondemand"></a></h4> <p>The flow for preparing On-Demand Content requires that a media asset is available non-encrypted, ideally in the maximum resolution so that an adaptive streaming presentation can be prepared.</p> <p>One possible flow is that a Content Management System (CMS) creates a workflow ensuring that DASH Content is prepared. The CMS makes the file available to a transcoder. The transcoder outputs the segmented files that can be encrypted. The encryption engine either generates the Content Keys or requests them from a DRM system. The DRM system also provides <code class="highlight">pssh</code> boxes to be added to the media files, as well as <code class="highlight">ContentProtection</code> elements to be added to the MPD file. When the encrypted DASH Content is ready, the MPD is generated by a MPD Generator It asks the DRM system the required DRM Signaling to be added in the MPD. DASH content is then uploaded by the CMS on a CDN making it available to users. In parallel, editorial metadata is exported to the Portal, enabling access to users. DRM systems receive relevant metadata information that needs to be included in the license (output controls) when creating a license.</p> <p>This flow is summarized in the figure below where arrows show the flow of information.</p> <figure> <img src="Images/ExampleWorkflow-OnDemand.png"> <figcaption>Example of workflow for On-Demand Content preparation.</figcaption> </figure> <h4 class="heading settled" data-level="6.3.3" id="usecases-packaging-live"><span class="secno">6.3.3. </span><span class="content">Live Content</span><a class="self-link" href="#usecases-packaging-live"></a></h4> <p>Metadata is regularly imported with new or updated information. Metadata can include different type of information on the EPG events such as the duration of the event, the list of actors, the output controls usage rules, a purchase window, etc.</p> <p>Content is continuously received, transcoded in the desired format and encrypted if any type of entitlement is required.</p> <p>One or many Content Keys can be used if key rotation is used or not. Such setting is static and configuration is hard-coded in the relevant equipment, hence a Content Management System is not required for this workflow to operate. As for Content on-Demand, keys are generated by the encryption engine or the DRM system and are available to all DRM systems and the encryption engine at the right moment depending on how these keys are used. The encoder requests to the DRM systems their specific signaling, if any, to be added in the MPD.</p> <p>Encrypted segments and the media manifest are uploaded on a CDN making it available to users.</p> <p>Metadata is exported to the Portal, enabling access to users. DRM systems receive relevant metadata information that needs to be included in the license (output controls).</p> <p>This flow is summarized in the figure below where arrows show the flow of information.</p> <figure> <img src="Images/ExampleWorkflow-Live.png"> <figcaption>Example of workflow for Live Content preparation.</figcaption> </figure> <h4 class="heading settled" data-level="6.3.4" id="usecases-packaging-catchup"><span class="secno">6.3.4. </span><span class="content">Catch-up</span><a class="self-link" href="#usecases-packaging-catchup"></a></h4> <p>Live Content has already been encoded and encrypted (if required) for Live unicast. All DRM systems have access to the keys.</p> <p>Additional metadata may be required for ensuring that events are effectively available in catch-up. These are made available to the Portal and some Live events are identified as being able to be replayed as On-demand. Optionally, the operator may choose to replace the advertising content with targeted ads.</p> <h3 class="heading settled" data-level="6.4" id="usecases-exchange"><span class="secno">6.4. </span><span class="content">Exchange over an Interface</span><a class="self-link" href="#usecases-exchange"></a></h3> <h4 class="heading settled" data-level="6.4.1" id="usecase-exchange-intro"><span class="secno">6.4.1. </span><span class="content">Introduction</span><a class="self-link" href="#usecase-exchange-intro"></a></h4> <p>This clause gives details on how content protection information is exchanged or transferred over an interface between two or more entities.</p> <h4 class="heading settled" data-level="6.4.2" id="usecases-exchange-deliverytoone"><span class="secno">6.4.2. </span><span class="content">Content Key Delivery to One Entity</span><a class="self-link" href="#usecases-exchange-deliverytoone"></a></h4> <p>In the simplest use case, content protection information is made of a Content Key. One entity sends a Content Key to the other entity.</p> <figure> <img src="Images/UseCase-ClearDeliveryToOne.png"> <figcaption>Content Key delivery to one entity.</figcaption> </figure> <p>The primary data model carried by content protection information document is made of one to many Content Keys with their associated KIDs. Any context or meaning is attributed externally. The document simply serves as a standard way to serialize Content Keys for delivery.</p> <h4 class="heading settled" data-level="6.4.3" id="usecases-exchange-securedeliverytomany"><span class="secno">6.4.3. </span><span class="content">Secure Content Key Delivery to Several Entities</span><a class="self-link" href="#usecases-exchange-securedeliverytomany"></a></h4> <p>This use case is an extension of clause <a href="#usecases-exchange-deliverytoone">�/ 6.4.2 Content Key Delivery to One Entity</a> and is compatible with the use cases presented in the following clauses.</p> <figure> <img src="Images/UseCase-EncryptedDeliveryToMany.png"> <figcaption>Secure Content Key delivery to several entities.</figcaption> </figure> <p>The entities exchanging Content Keys may want to rely upon a trust relationship that ensures authentication and privacy of communications. Such a mechanism can be provided by the communication protocol used to deliver the document but the document can also be self-protected. CPIX documents can deliver Content Keys in encrypted and digitally signed form, enabling confidentiality, authentication and nonrepudiation.</p> <p>In situations with more than one recipient, the document allows each one to decrypt the Content Keys using its own private key.</p> <h4 class="heading settled" data-level="6.4.4" id="usecases-exchange-usagerules"><span class="secno">6.4.4. </span><span class="content">Content Key Delivery with Usage Rules</span><a class="self-link" href="#usecases-exchange-usagerules"></a></h4> <h5 class="heading settled" data-level="6.4.4.1" id="usecases-exchange-usagerules-intro"><span class="secno">6.4.4.1. </span><span class="content">Introduction</span><a class="self-link" href="#usecases-exchange-usagerules-intro"></a></h5> <p>These use cases are extension of <a href="#usecases-exchange-deliverytoone">�/ 6.4.2 Content Key Delivery to One Entity</a> and present different rules that can be applied on a Content Key when delivered to an entity. Each usage rule defines a set of filters that are used to define a Content Key Context. If a rule match is found, the Content Key referenced by the usage rule is to be used to encrypt the Content Key Context defined by the rule.</p> <figure> <img src="Images/UseCase-DeliveryWithUsageRules.png"> <figcaption>Content Key delivery with key usage rules.</figcaption> </figure> <h5 class="heading settled" data-level="6.4.4.2" id="usecases-exchange-usagerules-labelfilter"><span class="secno">6.4.4.2. </span><span class="content">Label Filter</span><a class="self-link" href="#usecases-exchange-usagerules-labelfilter"></a></h5> <p>This use case adds information to Content Keys that specifies how they are to be mapped to labelled Content Key Contexts, where the labeling system has been pre-agreed between the producer and consumer of the CPIX document.</p> <p>For example, labels might be the IDs of DASH adaptation sets or, for more compatibility with formats other than DASH, names of media files/directories or input values for arbitrary custom logic.</p> <p>The recipient will use the added information to map Content Keys to Content Key Contexts defined by labels.</p> <h5 class="heading settled" data-level="6.4.4.3" id="usecases-exchange-usagerules-periodfilter"><span class="secno">6.4.4.3. </span><span class="content">Key Period Filter</span><a class="self-link" href="#usecases-exchange-usagerules-periodfilter"></a></h5> <p>This use case adds information to Content Keys that specifies how they are to be mapped to key periods, a.k.a. crypto-periods for Content Key rotation. The mapping is accomplished by defining key periods and mapping Content Keys to any number of key periods.</p> <p>The recipient will use the added information to map Content Keys to time periods.</p> <h5 class="heading settled" data-level="6.4.4.4" id="usecases-exchange-usagerules-policyfilters"><span class="secno">6.4.4.4. </span><span class="content">Policy-based Filters</span><a class="self-link" href="#usecases-exchange-usagerules-policyfilters"></a></h5> <p>This use case associates policy-based information with Content Keys, constraining how they define Content Key Contexts. Policy based filters are, for example, video or audio stream attributes and bitrate ranges.</p> <p>The recipient will use the added information to map Content Keys to Content Key Contexts according to the defined policy.</p> <p>Having no policy in some dimension means that the Content Key Context is not constrained in that dimension. For example, if the HDR policy is not specified, the Content Key Context may include both HDR and non-HDR media.</p> <h4 class="heading settled" data-level="6.4.5" id="usecases-exchange-drmsignaling"><span class="secno">6.4.5. </span><span class="content">Content Key Delivery with DRM Signaling</span><a class="self-link" href="#usecases-exchange-drmsignaling"></a></h4> <p>This use case is an extension of <a href="#usecases-exchange-deliverytoone">�/ 6.4.2 Content Key Delivery to One Entity</a> and is compatible with <a href="#usecases-exchange-usagerules">�/ 6.4.4 Content Key Delivery with Usage Rules</a>.</p> <p>This use case adds DRM Signaling information to each Content Key. The recipient may embed this signaling into the data streams it generates.</p> <figure> <img src="Images/UseCase-DeliveryWithDrmSignaling.png"> <figcaption>Content Key Delivery with DRM Signaling.</figcaption> </figure> <p>The primary data model carried by content protection information document needs then to include zero to many DRM system signaling elements, each element consisting of a DRM system ID, some signaling information such as for example signaling data for a DASH manifest or an HLS playlist or signaling data for an ISOBMFF file.</p> <p>The use of 3rd party extensions enable the inclusion of DRM system signaling in forms suitable for other media delivery technologies.</p> <p>The recipient may use the part of signaling data that it understands and knows how to embed into its output, ignoring signaling data that targets other media delivery technologies.</p> <h4 class="heading settled" data-level="6.4.6" id="usecases-exchange-incrementalauthoring"><span class="secno">6.4.6. </span><span class="content">Incremental Update and Extension of the Document</span><a class="self-link" href="#usecases-exchange-incrementalauthoring"></a></h4> <p>This use case illustrates the usage of the content protection information document in a realistic workflow comprising multiple cooperating components that require a standardized data format for content protection information exchange.</p> <figure> <img src="Images/UseCase-DeliveryWithIncrementalUpdate.png"> <figcaption>Incremental update and extension of the document.</figcaption> </figure> <p>Each component participating in such a workflow is the authority on a particular aspect. For example, the Key Server manages Content Keys and usage rules and may define the key periods, the DRM System knows how to define the correct DRM Signaling and the Encryption Engine might want to inform the Packager what representations the Content Keys actually got mapped to (the Packager might not have enough information to resolve usage rules based on detailed metadata, so the Encryption Engine could define a new set of usage rules that are simple enough for the Packager to understand, e.g. by making use of label filters).</p> <p>As the document travels in the workflow, each component adds the elements containing the content protection items it generates (key periods, usage rules, Content Keys, DRM Signaling, etc), making it suitable for the next component that will make use of it. After each modification, the added elements may be signed to maintain a chain of trust on each set of elements individually. The document in its entirety may also be signed to authenticate the document as a whole.</p> <p>Note that in the above example, the Content Key material itself is encrypted for the Encryption Engine. Despite the fact that many other components participate in the workflow, they do not have access to Content Keys.</p> <h4 class="heading settled" data-level="6.4.7" id="usecases-exchange-multipleassets"><span class="secno">6.4.7. </span><span class="content">Multiple Content Keys Delivery for Multiples Assets</span><a class="self-link" href="#usecases-exchange-multipleassets"></a></h4> <p>This use case is for the bulk transfer of Content Keys in one document. Each Content Key is associated to a different media asset, hence within the document, several media assets can be referenced. Limiting the number of documents to exchange allows for simpler transfer between entities of Content Keys and associated information such as usage rules and DRM signaling.</p> <figure> <img src="Images/UseCase-MultiplesAssets.png"> <figcaption>Bulk transfer of Content Keys referencing different assets.</figcaption> </figure> <h4 class="heading settled" data-level="6.4.8" id="usecases-exchange-hierarchydelivery"><span class="secno">6.4.8. </span><span class="content">Content Key Hierarchy Delivery for Content Packaging</span><a class="self-link" href="#usecases-exchange-hierarchydelivery"></a></h4> <p>Some DRM systems enable the use of hierarchy of keys, where the set of keys delivered to clients (root keys) within licenses differs from the set of keys used to encrypt Content (leaf keys). Doing so enables DRM systems to separate content encryption and commercial offer management.</p> <p>Packaging content that uses a key hierarchy requires the Packager to know:</p> <ul> <li data-md> <p>The leaf keys.</p> <li data-md> <p>The KIDs of the root keys (but not the root keys themselves).</p> <li data-md> <p>DRM system signaling data for both root and leaf keys.</p> </ul> <p>To fulfill this use case, CPIX enables the above data to be exchanged.</p> <h4 class="heading settled" data-level="6.4.9" id="usecases-exchange-rootkeydelivery"><span class="secno">6.4.9. </span><span class="content">Root Key Delivery for License Server Operation</span><a class="self-link" href="#usecases-exchange-rootkeydelivery"></a></h4> <p>Some DRM systems enable the use of hierarchical keys, where the set of keys delivered to clients (root keys) differs from the set of keys used to encrypt Content (leaf keys).</p> <p>When, for example, key creation is not a function of the license server, creating licenses in scenarios that use hierarchical keys requires the license server to know the root keys. CPIX enables root keys to be delivered to license servers.</p> <p>The exchange of root keys is technically identical to the exchange of non-hierarchical Content Keys as described in <a href="#usecases-exchange-deliverytoone">�/ 6.4.2 Content Key Delivery to One Entity</a>. It is expected that the recipient of a CPIX document in this use case is already aware of the hierarchical nature of the keys within, without any signaling in the CPIX document.</p> <h3 class="heading settled" data-level="6.5" id="usecases-workflows"><span class="secno">6.5. </span><span class="content">Workflow Examples</span><a class="self-link" href="#usecases-workflows"></a></h3> <h4 class="heading settled" data-level="6.5.1" id="usecases-workflows-encryptorandproducer"><span class="secno">6.5.1. </span><span class="content">Encryptor Producer and Encryptor Consumer</span><a class="self-link" href="#usecases-workflows-encryptorandproducer"></a></h4> <h5 class="heading settled" data-level="6.5.1.1" id="usecases-workflows-encryptorandproducer-intro"><span class="secno">6.5.1.1. </span><span class="content">Introduction</span><a class="self-link" href="#usecases-workflows-encryptorandproducer-intro"></a></h5> <p>There are many workflows that are possible, depending on which entities provide information in the CPIX document, and which entities consume that information. Two simple single-producer, single-consumer examples are illustrated below:</p> <figure> <img src="Images/Workflow-EncryptorProducer.png"> <figcaption>Encryptor Producer.</figcaption> </figure> <figure> <img src="Images/Workflow-EncryptorConsumer.png"> <figcaption>Encryptor Consumer.</figcaption> </figure> <p>All workflows require that content protection information and Content Keys be exchanged between two or more entities. In the examples above the entities are the Encryptor and DRM System:</p> <ul> <li data-md> <p>The Encryptor Producer example allows, in this case, the Encryptor to generate Content Keys and to push them to one or many DRM systems. The Encryptor could expect to receive from the DRM systems some DRM Signaling.</p> <li data-md> <p>The Encryptor Consumer example allows the Encryptor to pull Content Keys and DRM Signaling from a DRM system. In this case, Content Keys are generated by the DRM System.</p> </ul> <p>The document allows supporting both workflows above in addition to other workflows not explicitly described here.</p> <p>Before exchanging key information in a secure manner, the entities which exchange key material musshallt know about each other and share public keys so that one entity could encrypt data and the other entity could decrypt it. This important step of Trust establishment is out of the scope of this document.</p> <h5 class="heading settled" data-level="6.5.1.2" id="usecases-workflows-encryptorandproducer-encryptorproducer"><span class="secno">6.5.1.2. </span><span class="content">Encryptor Producer</span><a class="self-link" href="#usecases-workflows-encryptorandproducer-encryptorproducer"></a></h5> <p>This clause shows a possible workflow for securing the exchange of the key information between entities when the Encryptor generates the Content Keys. In this example, the Encryptor is the entity which is taking responsibility for generating the Content Keys, protecting them and pushing them to the DRM Systems.</p> <ul> <li data-md> <p>The first step is the Trust establishment. Public keys shall be exchanged between two or more entities (the Encryptors and the DRM Systems) prior exchanges.</p> <li data-md> <p>Once the Trust is established and the necessary associated key material is shared between entities, Content Keys can be exchanged. The Encryptor is encrypting these keys using DRM Systems public keys. The DRM Systems can decrypt using their own private key.</p> <li data-md> <p>The Encryptor provides crypto material required to uniquely identify the entity capable of decrypting the media.</p> </ul> <p>All these steps are summarized in the figure below.</p> <figure> <img src="Images/Workflow-EncryptorProducer-Steps.png"> <figcaption>Encryptor Producer example steps.</figcaption> </figure> <h5 class="heading settled" data-level="6.5.1.3" id="usecases-workflows-encryptorandproducer-encryptorconsumer"><span class="secno">6.5.1.3. </span><span class="content">Encryptor Consumer</span><a class="self-link" href="#usecases-workflows-encryptorandproducer-encryptorconsumer"></a></h5> <p>This clause shows a possible workflow for securing the exchange of the key information between entities when the DRM System generates the Content Keys. In this model, the Encryptor can pull documents directly from a DRM System. In this case, the DRM System is generating Content Keys and is encrypting them for a secure delivery to the Encryptor.</p> <ul> <li data-md> <p>As in the case of the Encryptor Producer model, the first step is the Trust establishment. Public keys shall be exchanged between two or more entities (the Encryptors and the DRM System) prior exchanges.</p> <li data-md> <p>The DRM System will use the public key of the Encryptor to encrypt keys to be inserted in the document and will send it to Encryptor.</p> <li data-md> <p>The Encryptor can decrypt the Content Keys using its private key.</p> </ul> <p>All these steps are summarized in the figure below.</p> <figure> <img src="Images/Workflow-EncryptorConsumer-Steps.png"> <figcaption>Encryptor Consumer example steps.</figcaption> </figure> <h4 class="heading settled" data-level="6.5.2" id="usecases-workflows-multipleproducers"><span class="secno">6.5.2. </span><span class="content">Multiple Producers</span><a class="self-link" href="#usecases-workflows-multipleproducers"></a></h4> <p>This clause illustrates that it is possible to have more complex workflows than those previously illustrated. In one such example, for DASH content, a media packager might define the types of streams in the presentation, an Encryptor might generate the Content Keys, a DRM System might generate other DRM Signaling, An Encryptor and an MPD Generator might be the consumers of the final document. In such workflows, the document gets passed from entity to entity in sequence, with each entity adding top-level elements, and recording the update.</p> <figure> <img src="Images/Workflow-MultipleProducers.png"> <figcaption>Multiple Producers example.</figcaption> </figure> <ul> <li data-md> <p>The first step is the Trust establishment. Public keys shall be exchanged between two or more entities prior to exchanges.</p> <li data-md> <p>Once the Trust is established and the necessary associated key material is shared between entities, Content Keys can be exchanged.</p> <li data-md> <p>The Packager provides identification of the receivers and the various stream encoding criteria (usage rules) in version 1 of the document.</p> <li data-md> <p>The Encryptor adds key information in version 2 of the document. These elements only contain Keys and no DRM information.</p> <li data-md> <p>The DRM System imports the Content Keys stored in the document, and adds its own information in version 3 of the document, which is the finalized version.</p> <li data-md> <p>The Encryptor extracts content protection information from the document to be embedded in the media (e.g. <code class="highlight">pssh</code> boxes).</p> <li data-md> <p>The MPD Generator also extracts content protection related information from the document to be embedded in the MPD document (e.g. <code class="highlight">pssh</code> boxes, key IDs).</p> </ul> <p>All these steps are summarized in the figure below.</p> <figure> <img src="Images/Workflow-MultipleProducers-Steps.png"> <figcaption>Multiple Producers example steps.</figcaption> </figure> <h2 class="heading settled" data-level="7" id="schema"><span class="secno">7. </span><span class="content">XSD Schema Definition</span><a class="self-link" href="#schema"></a></h2> <h3 class="heading settled" data-level="7.1" id="schema-intro"><span class="secno">7.1. </span><span class="content">Introduction</span><a class="self-link" href="#schema-intro"></a></h3> <p>This clause describes the Content Protection Information eXchange (CPIX) format to provide a framework to securely exchange Content Key(s) and DRM Signaling between different system entities (see clause <a href="#usecases">�/ 6 Use Cases and Requirements</a>). This is an XML file. This clause describes in details elements part of the schema.</p> <h3 class="heading settled" data-level="7.2" id="schema-requirements"><span class="secno">7.2. </span><span class="content">Requirements</span><a class="self-link" href="#schema-requirements"></a></h3> <p>It shall be possible to exchange Content Key(s) and DRM Signaling between entities involved in Content preparation workflows, an example of such interface where the exchange shall be possible is between a DRM system and the encryption engine.</p> <p>It shall be possible that the manifest generator receives DRM Signaling for several DRM systems and/or content formats.</p> <p>Update of Content Key(s) shall be possible at periodic time or based on events. Some period of time could be in the clear (no encryption).</p> <p>It shall allow generating MPD conformant to <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a>.</p> <p>Content Key(s) shall be secured over the interface.</p> <p>Entities exchanging content protection information should be authenticated.</p> <h3 class="heading settled" data-level="7.3" id="schema-structure"><span class="secno">7.3. </span><span class="content">Structure Overview</span><a class="self-link" href="#schema-structure"></a></h3> <p>The structure is articulated around Content Keys and the accompanying material. The document contains all the information required for allowing any entitled entity to get access to or add in the Content Keys and either consume or add material, such as time constraint, DRM information to the CPIX document. The same XML file can be shared between several receiving entities. Hence, each one shall be able to decrypt keys and shall be properly identified.</p> <p>Taking this into account, the CPIX document contains lists of elements:</p> <ul> <li data-md> <p><code class="highlight">DeliveryDataList</code>: This list contains instances of <code class="highlight">DeliveryData</code>, each of which describes an entity entitled to decrypt Content Keys contained in the CPIX document.</p> <li data-md> <p><code class="highlight">ContentKeyList</code>: This list contains instances of <code class="highlight">ContentKey</code>, each of which contains a Content Key used for encrypting media.</p> <li data-md> <p><code class="highlight">DRMSystemList</code>: This list contains instances of <code class="highlight">DRMSystem</code>, each of which contains the signaling data to associate one DRM system with one Content Key.</p> <li data-md> <p><code class="highlight">ContentKeyPeriodList</code>: This list contains instances of <code class="highlight">ContentKeyPeriod</code>, each of which defines a time period that may be referenced by the key period filters included in Content Key usage rules.</p> <li data-md> <p><code class="highlight">ContentKeyUsageRuleList</code>: This list contains instances of <code class="highlight">ContentKeyUsageRule</code>, which maps a Content Key to one or more Content Key Contexts.</p> <li data-md> <p><code class="highlight">UpdateHistoryItemList</code>: This list contains instances of <code class="highlight">UpdateHistoryItem</code>, each of which contains an update version number and an identifier of the entity which produced the update. Other elements in the document are linked to a specific update by update version number (via the <code class="highlight">@updateVersion</code> attribute).</p> <li data-md> <p><code class="highlight">Signature</code>: Each instance of this element contains a digital signature <a data-link-type="biblio" href="#biblio-xmldsig-core" title="W3C� Recommendation 11 April 2013: XML Signature Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, David Solo, et al. (Second Edition), 10 June 2008">[XMLDSIG-CORE]</a> over either the entire document or a subset of XML elements.</p> </ul> <p>The Content Keys can be encrypted inside the XML file using the public keys of the recipients, identified in the <code class="highlight">DeliveryData</code> elements. The XML file also allows storing the Content Keys in the clear, in which case the security of the Content Keys is contingent on the security of the communication channel used to deliver the CPIX document to the recipients.</p> <p>The figure below shows the first elements and a high-level view of the structure. Detailed description of the structure is given in the following clauses.</p> <figure> <img src="Images/Schema-CpixView.png"> <figcaption>Content Protection Information Exchange Format high level view.</figcaption> </figure> <h3 class="heading settled" data-level="7.4" id="schema-datamodel"><span class="secno">7.4. </span><span class="content">Hierarchical Data Model</span><a class="self-link" href="#schema-datamodel"></a></h3> <h4 class="heading settled" data-level="7.4.1" id="schema-datamodel-intro"><span class="secno">7.4.1. </span><span class="content">Introduction</span><a class="self-link" href="#schema-datamodel-intro"></a></h4> <p>In this clause, the following conventions are used:</p> <ul> <li data-md> <p>Element names are in <code class="highlight">PascalCase</code> and the number of allowed instances is defined by (<code class="highlight">min...max</code>) where N for <code class="highlight">max</code> means unbounded.</p> <li data-md> <p>Attribute names are in <code class="highlight">camelCase</code> preceded with an <code class="highlight">@</code> and the use of an attribute is defined as: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. Attributes may be in any order.</p> </ul> <p>The XSD schema for this model is provided <a href="https://dashif.org/guidelines/others/#dash-if-content-protection-information-exchange-format">here</a>.</p> <p>In addition to types defined in this document that come with the prefix <code class="highlight">cpix:</code>, , the CPIX data model references types defined in <a data-link-type="biblio" href="#biblio-xmlschema11-2" title="W3C� Recommendation 5 April 2012: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, David Peterson et al">[XMLSCHEMA11-2]</a>, <a data-link-type="biblio" href="#biblio-rfc6030" title="IETF RFC 6030: Portable Symmetric Key Container (PSKC), October 2010">[RFC6030]</a>, <a data-link-type="biblio" href="#biblio-xmldsig-core" title="W3C� Recommendation 11 April 2013: XML Signature Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, David Solo, et al. (Second Edition), 10 June 2008">[XMLDSIG-CORE]</a> and <a data-link-type="biblio" href="#biblio-xmlenc-core" title="W3C� Recommendation 11 April 2013: XML Encryption Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, 10 December 2002">[XMLENC-CORE]</a>. External data types are prefixed with <code class="highlight">xs:</code>, <code class="highlight">pskc:</code>, <code class="highlight">ds:</code> and <code class="highlight">xenc:</code> respectively.</p> <h4 class="heading settled" data-level="7.4.2" id="schema-datamodel-cpix"><span class="secno">7.4.2. </span><span class="content"><code class="highlight">CPIX</code> Element</span><a class="self-link" href="#schema-datamodel-cpix"></a></h4> <p>The root element that carries the Content Protection Information for a set of media assets.</p> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the CPIX document. It is recommended to use an identifier that is unique within the scope in which this file is published.</p> <dt data-md><code class="highlight">@contentId (O, xs:string)</code> <dd data-md> <p>An identifier for the asset or content that is protected by the keys carried in this CPIX document. It is recommended to use an identifier that is unique within the scope in which this file is published. It is mutually exclusive with the attribute <code class="highlight">@contentId</code> defined in the <code class="highlight">ContentKey</code> element.</p> <dt data-md><code class="highlight">@name (O, xs:string)</code> <dd data-md> <p>A name for the presentation.</p> <dt data-md><code class="highlight">@version (O, xs:string)</code> <dd data-md> <p>A version for the CPIX document. The value shall reference a published version of the CPIX guidelines and be structured as majorVersion.minorVersion. This specification describes version 2.4.</p> <dd data-md> <p>If the CPIX client knows that it doesn t support all the features of a given CPIX version, it needs to behave according to the recommendations of the API used to exchange the CPIX document.</p> <dt data-md><code class="highlight">DeliveryDataList (0...1, cpix:DeliveryDataList)</code> <dd data-md> <p>A container for <code class="highlight">DeliveryData</code> elements. If not present, Content Keys in the document are delivered in the clear, without encryption.</p> <dt data-md><code class="highlight">ContentKeyList (0...1, cpix:ContentKeyList)</code> <dd data-md> <p>A container for <code class="highlight">ContentKey</code> elements.</p> <dt data-md><code class="highlight">DRMSystemList (0...1, cpix:DRMSystemList)</code> <dd data-md> <p>A container for <code class="highlight">DRMSystem</code> elements. If not present, the document does not contain any DRM system signaling data.</p> <dt data-md><code class="highlight">ContentKeyPeriodList (0...1, cpix:ContentKeyPeriodList)</code> <dd data-md> <p>A container for <code class="highlight">ContentKeyPeriod</code> elements.</p> <dt data-md><code class="highlight">ContentKeyUsageRuleList (0...1, cpix:ContentKeyUsageRuleList)</code> <dd data-md> <p>A container for <code class="highlight">ContentKeyUsageRule</code> elements. If not present, the document does not define Content Key Contexts and an external mechanism is required for synchronizing the content creation workflow.</p> <dt data-md><code class="highlight">UpdateHistoryItemList (0...1, cpix:UpdateHistoryItemList)</code> <dd data-md> <p>A container for <code class="highlight">UpdateHistoryItem</code> elements.</p> <dt data-md><code class="highlight">Signature (0...N, ds:Signature)</code> <dd data-md> <p>Digital signatures as defined in <a data-link-type="biblio" href="#biblio-xmldsig-core" title="W3C� Recommendation 11 April 2013: XML Signature Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, David Solo, et al. (Second Edition), 10 June 2008">[XMLDSIG-CORE]</a>. Each signature signs either the full document or any set of elements within the CPIX document. Every digital signature shall contain an X.509 certificate identifying the signer and the associated public key.</p> </dl> <figure> <img src="Images/Schema-Cpix.png"> <figcaption>CPIX element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.3" id="schema-datamodel-deliverydatalist"><span class="secno">7.4.3. </span><span class="content"><code class="highlight">DeliveryDataList</code> Element</span><a class="self-link" href="#schema-datamodel-deliverydatalist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">DeliveryData (1...N, cpix:DeliveryData)</code> <dd data-md> <p>Contains the required information allowing defining which entities can get access to the Content Keys delivered in this document.</p> <dd data-md> <p>There is one <code class="highlight">DeliveryData</code> element per entity capable of accessing encrypted Content Keys stored in this document. If this element is not present, then the Content Keys are in the clear in the file.</p> </dl> <figure> <img src="Images/Schema-DeliveryDataList.png"> <figcaption>DeliveryDataList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.4" id="schema-datamodel-deliverydata"><span class="secno">7.4.4. </span><span class="content"><code class="highlight">DeliveryData</code> Element</span><a class="self-link" href="#schema-datamodel-deliverydata"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">@name (O, xs:string)</code> <dd data-md> <p>Name of the Delivery Data.</p> <dt data-md><code class="highlight">DeliveryKey (1, ds:KeyInfoType)</code> <dd data-md> <p>Contains an X.509 certificate that identifies the intended recipient and the public key that was used to encrypt the Document Key.</p> <dd data-md> <p>Refer to <a href="#keys-enc">�/ 8.1 Key Encryption and Authentication in the CPIX Document</a> for a description of the key management within the CPIX document.</p> <dt data-md><code class="highlight">DocumentKey (1...N, cpix:DocumentKeyType)</code> <dd data-md> <p>Contains the keys that are used for encrypting the Content Key stored in <code class="highlight">ContentKey</code> elements.</p> <dt data-md><code class="highlight">MACMethod (0...1, pskc:MACMethodType)</code> <dd data-md> <p>Identifies the MAC algorithm and contains the MAC key used to implement authenticated encryption of Content Keys. The key in the MACKey element is encrypted using the public key listed in the recipient s X.509 certificate from the DeliveryKey element.</p> <dd data-md> <p>Refer to <a href="#keys-enc">�/ 8.1 Key Encryption and Authentication in the CPIX Document</a> for a description of the key management within the CPIX document.</p> <dt data-md><code class="highlight">Description (0...1, xs:string)</code> <dd data-md> <p>A description of the element.</p> <dt data-md><code class="highlight">SendingEntity (0...1, xs:string)</code> <dd data-md> <p>The name of the entity generating this CPIX document.</p> <dt data-md><code class="highlight">SenderPointOfContact (0...1, xs:string)</code> <dd data-md> <p>The contact information, such as an email address, of the entity generating this CPIX document.</p> <dt data-md><code class="highlight">ReceivingEntity (0...1, xs:string)</code> <dd data-md> <p>The name of the entity capable of decrypting Content Keys in this CPIX document.</p> </dl> <figure> <img src="Images/Schema-DeliveryData.png"> <figcaption>DeliveryData element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.5" id="schema-datamodel-documentkey"><span class="secno">7.4.5. </span><span class="content"><code class="highlight">DocumentKey</code> Element</span><a class="self-link" href="#schema-datamodel-documentkey"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@encryptsKey (O, cpix:UUID)</code> <dd data-md> <p>Matches the <code class="highlight">@kid</code> attribute(s) of the referenced ContentKey elements. These referenced Content Keys in the <code class="highlight">ContentKey</code> element(s) are encrypted with the Document Key stored under the <code class="highlight">Data</code> element. When a Document Key is used for encrypting several Content Keys, this attribute shall store a space-delimited list of those different <code class="highlight">@kid</code> values.</p> <dd data-md> <p>If there are several <code class="highlight">DocumentKey</code> elements, this attribute shall be present. If there is only one <code class="highlight">DocumentKey</code> element, this attribute may not be present and, in this case, the Document Key encrypts all Content Keys.</p> <dt data-md><code class="highlight">Data (1, pskc:KeyDataType)</code> <dd data-md> <p>Contains the Document Key either in the clear or encrypted. The Document Keys are encrypted using the public key listed in the recipient s X.509 certificate from the DeliveryKey element.</p> <dd data-md> <p>Refer to <a href="#keys-enc">�/ 8.1 Key Encryption and Authentication in the CPIX Document</a> for a description of the key management within the CPIX document.</p> </dl> <figure> <img src="Images/Schema-DocumentKey.png"> <figcaption>DocumentKey element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.6" id="schema-datamodel-contentkeylist"><span class="secno">7.4.6. </span><span class="content"><code class="highlight">ContentKeyList</code> Element</span><a class="self-link" href="#schema-datamodel-contentkeylist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">ContentKey (1...N, cpix:ContentKey)</code> <dd data-md> <p>Contains all information on a Content Key used to encrypt one or more Content Key Contexts.</p> </dl> <figure> <img src="Images/Schema-ContentKeyList.png"> <figcaption>ContentKeyList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.7" id="schema-datamodel-contentkey"><span class="secno">7.4.7. </span><span class="content"><code class="highlight">ContentKey</code> Element</span><a class="self-link" href="#schema-datamodel-contentkey"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@contentId (O, xs:string)</code> <dd data-md> <p>An identifier for the asset or content that is protected by this key. It is mutually exclusive with the attribute <code class="highlight">@contentId</code> defined in the <code class="highlight">CPIX</code> element.</p> <dd data-md> <p>When present, every <code class="highlight">ContentKey</code> element may have different or identical value. This attribute shall not be present if the <code class="highlight">@dependsOnKey</code> attribute is present. In a key hierarchy, the root key defines this value for all keys in the hierarchy.</p> <dd data-md> <p>The use of this attribute is recommended only when exchanging multiples content keys that do not share the same <code class="highlight">@contentId</code> value. That allows reducing the number of documents that need to be exchanged. See <a href="#usecases-exchange-multipleassets">�/ 6.4.7 Multiple Content Keys Delivery for Multiples Assets</a> for additional details.</p> <dt data-md><code class="highlight">@kid (M, cpix:UUIDType)</code> <dd data-md> <p>The unique identifier of the Content Key. It shall be formatted as defined in <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a>, clause 11.2.</p> <dt data-md><code class="highlight">@explicitIV (O, xs:base64binary)</code> <dd data-md> <p>The IV associated with the Content Key. This is a 128-bit value in binary format, base64-encoded. This is the value of <code class="highlight">Constant IV</code> defined in <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a> or of the <code class="highlight">IV</code> attribute under <code class="highlight">#EXT-X-KEY</code> or <code class="highlight">#EXT-X-SESSION-KEY</code> defined in <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a> if content is delivered in HLS format.</p> <dd data-md> <p>Use of this attribute is not recommended except for compatibility with some DRM systems that explicitly need it, meaning when a <code class="highlight">Constant IV</code> needs to be provided within a DRM license.</p> <dt data-md><code class="highlight">@dependsOnKey (O, cpix:UUIDType)</code> <dd data-md> <p>This attribute signals that the Content Key is a leaf key in a key hierarchy. It references the <code class="highlight">@kid</code> attribute of another <code class="highlight">ContentKey</code> element describing the root key.</p> <dd data-md> <p>The referenced key shall not be a leaf key.</p> <dd data-md> <p>If this attribute is not specified, the Content Key is either a root key or does not participate in a key hierarchy. The CPIX document format does not make a distinction between these two cases.</p> <dd data-md> <p>Note all DRMs support key hierarchy, see <a href="#keys-rotation">�/ 8.2 Key Rotation Support</a> for more details.</p> <dt data-md><code class="highlight">@commonEncryptionScheme (O, xs:string)</code> <dd data-md> <p>The encryption scheme that the content key is intended to be used with. When present, the value shall be a 4-character Common Encryption protection scheme name as defined by <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a> or one of the encryption method defined in <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a>. If the attribute is omitted then content may be encrypted using any encryption scheme.</p> <dd data-md> <p>This attribute shall not be present if the <code class="highlight">@dependsOnKey</code> attribute is present. In a key hierarchy, the root key defines the encryption scheme for all keys in the hierarchy.</p> <dt data-md><code class="highlight">HDCPData (0...1, cpix:HDCPData)</code> <dd data-md> <p>Contains the HDCP information for this Content Key.</p> <dd data-md> <p>This attribute shall not be present if the <code class="highlight">@dependsOnKey</code> attribute is present. In a key hierarchy, the root key defines the HDCP properties for all keys in the hierarchy.</p> <dt data-md><code class="highlight">Data (0...1, pskc:KeyDataType)</code> <dd data-md> <p>Contains the Content Key either in the clear or encrypted. If encrypted, the Content Key is encrypted with a key that is under a <code class="highlight">DocumentKey</code> element.</p> <dd data-md> <p>Refer to <a href="#keys-enc">�/ 8.1 Key Encryption and Authentication in the CPIX Document</a> for a description of the key management within the CPIX document.</p> </dl> <figure> <img src="Images/Schema-ContentKey.png"> <figcaption>ContentKey element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.8" id="schema-datamodel-HDCPdata"><span class="secno">7.4.8. </span><span class="content"><code class="highlight">HDCPData</code> Element</span><a class="self-link" href="#schema-datamodel-HDCPdata"></a></h4> <dl> <dt data-md><code class="highlight">@HLSHDCPLevel (O, xs:string)</code> <dd data-md> <p>This attribute specifies the value of the <code class="highlight">HDCP-LEVEL</code> attribute of the <code class="highlight">EXT-X-STREAM-INF</code> tag in the multiVariant playlist. Its format is as specified in clause 4.4.6.2 of <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a>.</p> <dd data-md> <p>This attribute has meaning only when an HLS playlist is created for the media content.</p> <dt data-md><code class="highlight">HDCPOutputProtectionData (0...1, xs:base64binary)</code> <dd data-md> <p>This is the full well-formed standalone XML fragment to be added to the DASH manifest for the HDCP <code class="highlight">OutputProtection</code> element for this Content Key. This is UTF-8 text without a byte order mark. See in <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a>, clause 7.4 for more details.</p> <dd data-md> <p>This element has meaning only when a DASH manifest is created for the media content.</p> </dl> <figure> <img src="Images/Schema-HDCPData.png"> <figcaption>ContentKey element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.9" id="schema-datamodel-drmsystemlist"><span class="secno">7.4.9. </span><span class="content"><code class="highlight">DRMSystemList</code> Element</span><a class="self-link" href="#schema-datamodel-drmsystemlist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">DRMSystem (1...N, cpix:DRMSystem)</code> <dd data-md> <p>DRM Signaling of a DRM system associated with a Content Key.</p> </dl> <figure> <img src="Images/Schema-DRMSystemList.png"> <figcaption>DRMSystemList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.10" id="schema-datamodel-drmsystem"><span class="secno">7.4.10. </span><span class="content"><code class="highlight">DRMSystem</code> Element</span><a class="self-link" href="#schema-datamodel-drmsystem"></a></h4> <p>This element contains all information on a DRM system that can be used for retrieving licenses for getting access to content. This specification defines elements for DRM system signaling in DASH, ISOBMFF, Smooth Streaming and HLS. Implementations may extend CPIX documents with additional elements to provide DRM system signaling information for other formats.</p> <p>The DRM system signaling data in <code class="highlight">DRMSystem</code> elements often contains the protection scheme identifier in a DRM or streaming protocol system specific format. Values in <code class="highlight">DRMSystem</code> elements shall be aligned with the values in <code class="highlight">@commonEncryptionScheme</code> attributes of the <code class="highlight">ContentKey</code> elements.</p> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">@systemId (M, cpix:UUIDType)</code> <dd data-md> <p>This is the unique identifier of the DRM system. Values are avaialble on <a href="https://dashif.org/identifiers/content_protection/">dashif.org</a>.</p> <dt data-md><code class="highlight">@kid (M, cpix:UUIDType)</code> <dd data-md> <p>Matches the <code class="highlight">@kid</code> attribute of the <code class="highlight">ContentKey</code> this element references.</p> <dt data-md><code class="highlight">@name (O, xs:string)</code> <dd data-md> <p>This is a human-readable name and version of the DRM system. This can be used in a MPD as the value for the <code class="highlight">@value</code> attribute of the <code class="highlight">ContentProtection</code> element.</p> <dt data-md><code class="highlight">@HLSAllowedCPC (O, xs:string)</code> <dd data-md> <p>This attribute specifies, for the DRM identified by the <code class="highlight">@systemId</code> value, the value to be added in the <code class="highlight">ALLOWED-CPC</code> attribute of the <code class="highlight">EXT-X-STREAM-INF</code> tag in the multiVariant playlist. Its format is as specified in clause 4.4.6.2 of <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a>.</p> <dd data-md> <p>The final value of the <code class="highlight">ALLOWED-CPC</code> is the concatenation, each separated by a comma, of all <code class="highlight">@HLSAllowedCPC</code> values present in the CPIX document, except if <code class="highlight">ContentKey</code> elements have a <code class="highlight">@contentId</code> value. In this latter case, the concatenation is limited to those that have a referenced <code class="highlight">ContentKey</code> element with the same <code class="highlight">@contentId</code> value.</p> <dd data-md> <p>This attribute has meaning only when an HLS playlist is created for the media content.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element includes a <code class="highlight">@dependsOnKey</code> attribute, this element shall not be used.</p> <dt data-md><code class="highlight">PSSH (0...1, xs:base64binary)</code> <dd data-md> <p>This is the full <code class="highlight">pssh</code> box that should be added to ISOBMFF files encrypted with the referenced Content Key.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element includes a <code class="highlight">@dependsOnKey</code> attribute, the value shall be inserted under the <code class="highlight">moof</code> box.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element does not include a <code class="highlight">@dependsOnKey</code> attribute, the value may be inserted under the <code class="highlight">moov</code> box or the <code class="highlight">moof</code> box. In this case, see <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a>, clause 6 for more details.</p> <dt data-md><code class="highlight">ContentProtectionData (0...1, cpix:ContentProtectionData)</code> <dd data-md> <p>This is the full well-formed standalone XML fragment to be added to the DASH manifest under the <code class="highlight">ContentProtection</code> element for this DRM system. This is UTF-8 text without a byte order mark. An example of such data is the W3C signaling defined in <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a>, in this case, all <code class="highlight">dashif:xxx</code> elements are children of the <code class="highlight">ContentProtection</code> element and are therefore provided in this element.</p> <dd data-md> <p>This element has meaning only when a DASH manifest is created for the media content.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element includes a <code class="highlight">@dependsOnKey</code> attribute, this element shall not be used.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element does not include a <code class="highlight">@dependsOnKey</code> attribute, the value may be added under the <code class="highlight">ContentProtection</code> element for this DRM system.</p> <dt data-md><code class="highlight">HLSSignalingData (0...2, cpix:HLSSignalingData)</code> <dd data-md> <p>This is the full data including the <code class="highlight">#EXT-X-KEY</code> or <code class="highlight">#EXT-X-SESSION-KEY</code> tag of a HLS playlist <a data-link-type="biblio" href="#biblio-hls" title="R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft">[HLS]</a> depending on the destination of the data (see <a href="#schema-datamodel-HLSsignalingdata">�/ 7.4.12 HLSSignalingData Element</a>). This may contain multiple lines allowing to add lines with proprietary tags and values. This is UTF-8 text without a byte order mark.</p> <dd data-md> <p>This element shall not be used if the referenced Content Key is a leaf key in a key hierarchy.</p> <dd data-md> <p>This element has meaning only when a HLS playlist is created for the media content.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element includes a <code class="highlight">@dependsOnKey</code> attribute, this element shall not be present.</p> <dt data-md><code class="highlight">SmoothStreamingProtectionHeaderData</code> (0...1, xs:string) <dd data-md> <p>This is the inner text of the <code class="highlight">ProtectionHeader</code> element to be added to the Smooth Streaming manifest for this DRM system. This is UTF-8 text without a byte order mark.</p> <dd data-md> <p>This element has meaning only when a Smooth Streaming manifest is created for the media content.</p> <dd data-md> <p>If the referenced <code class="highlight">ContentKey</code> element includes a <code class="highlight">@dependsOnKey</code> attribute, this element shall not be present.</p> </dl> <p>Additional child elements may be present containing signaling data for other media formats. Such elements shall appear after any elements defined here.</p> <figure> <img src="Images/Schema-DRMSystem.png"> <figcaption>DRMSystem element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.11" id="schema-datamodel-contentprotectiondata"><span class="secno">7.4.11. </span><span class="content"><code class="highlight">ContentProtectionData</code> Element</span><a class="self-link" href="#schema-datamodel-contentprotectiondata"></a></h4> The <code class="highlight">ContentProtectionData</code> shall be base64 encoded text. It has an optional attribute allowing to define the robustness level that is expected for this DRM. <dl> <dt data-md><code class="highlight">@robustness (O, xs:string)</code> <dd data-md> <p>The value of this attribute is DRM specific. It announces what robustness level is expected from the DRM system for the representations that are encrypted by the referenced Content Key.</p> <dd data-md> <p>This is the value of the <code class="highlight">@robustness</code> attribute of the <code class="highlight">ContentProtection</code> element in the DASH manifest for this DRM system.</p> </dl> <figure> <img src="Images/Schema-ContentProtectionData.png"> <figcaption>DRMSystem element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.12" id="schema-datamodel-HLSsignalingdata"><span class="secno">7.4.12. </span><span class="content"><code class="highlight">HLSSignalingData</code> Element</span><a class="self-link" href="#schema-datamodel-HLSsignalingdata"></a></h4> <p>The <code class="highlight">HLSSignalingData</code> shall be base64 encoded text. It has an optional attribute allowing to define where this data is to be placed, either in the multiVariant playlist or in the media playlist. It allows having different proprietary signaling in these locations. In a <code class="highlight">DRMSystem</code> element, every <code class="highlight">HLSSignalingData</code> shall have a different <code class="highlight">@playlist</code> value if present. If <code class="highlight">@playlist</code> is not present then the <code class="highlight">HLSSignalingData</code> goes in the media playlist and there is no signaling in the multiVariant playlist (in this case, there is only one <code class="highlight">HLSSignalingData</code> element in the <code class="highlight">DRMSystem</code> element).</p> <dl> <dt data-md><code class="highlight">@playlist (O, restricted xs:string)</code> <dd data-md> <p>Specifies the destination of the data carried by this element. It can only have two values <code class="highlight">multiVariant</code> and <code class="highlight">media</code>. There is a uniqueness rule for this attribute. If two elements are added under a <code class="highlight">DRMSystem</code> element, they shall not have the same <code class="highlight">@playlist</code> value.</p> </dl> <figure> <img src="Images/Schema-HLSSignalingData.png"> <figcaption>HLSSignalingData element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.13" id="schema-datamodel-contentkeyperiodlist"><span class="secno">7.4.13. </span><span class="content"><code class="highlight">ContentKeyPeriodList</code> Element</span><a class="self-link" href="#schema-datamodel-contentkeyperiodlist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">ContentKeyPeriod (1...N, cpix:ContentKeyPeriod)</code> <dd data-md> <p>For every Content Key, <code class="highlight">ContentKeyPeriod</code> elements cover non ovelapping periods of time. The concatenation of all period of times may not fully cover the Content as some parts may be in the clear.</p> </dl> <figure> <img src="Images/Schema-ContentKeyPeriodList.png"> <figcaption>ContentKeyPeriodList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.14" id="schema-datamodel-contentkeyperiod"><span class="secno">7.4.14. </span><span class="content"><code class="highlight">ContentKeyPeriod</code> Element</span><a class="self-link" href="#schema-datamodel-contentkeyperiod"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@index (O, xs:integer)</code> <dd data-md> <p>Numerical index for the key period. It shall increase. When reaching MAX_UINT32, the value rolls over.</p> <dt data-md><code class="highlight">@label (O, xs:string)</code> <dd data-md> <p>String identifier for the key period. As an example, the value of this attribute may be used to match a SCTE-35 <code class="highlight">segmentation_event_id</code>, in this case, it allows matching this content key to a specific program.</p> <dt data-md><code class="highlight">@start (O, xs:dateTime)</code> <dd data-md> <p>For Live content, this is the wall clock time for the start time for the period.</p> <dt data-md><code class="highlight">@end (O, xs:dateTime)</code> <dd data-md> <p>For Live content, this is the wall clock time for the end time for the period. Mutually exclusive with <code class="highlight">@duration</code>.</p> <dt data-md><code class="highlight">@startOffset (O, xs:duration)</code> <dd data-md> <p>For VOD content, this is the start time for the period.</p> <dt data-md><code class="highlight">@endOffset (O, xs:duration)</code> <dd data-md> <p>For VOD content, this is the end time for the period. Mutually exclusive with <code class="highlight">@duration</code>.</p> <dt data-md><code class="highlight">@duration (O, xs:duration)</code> <dd data-md> <p>For VOD and Live content, this is the duration for the period. Mutually exclusive with <code class="highlight">@end</code> and <code class="highlight">@endOffset</code>.</p> </dl> <p>The valid combinations of attributes are:</p> <ul> <li data-md> <p><code class="highlight">@start</code> and <code class="highlight">@end</code> are present, the interval is defined by [<code class="highlight">@start</code>, <code class="highlight">@end</code>).</p> <li data-md> <p><code class="highlight">@start</code> and <code class="highlight">@duration</code> are present, the interval is defined by [<code class="highlight">@start</code>, <code class="highlight">@start</code>+<code class="highlight">@duration</code>).</p> <li data-md> <p><code class="highlight">@startOffset</code> and <code class="highlight">@endOffset</code> are present, the interval is defined by [<code class="highlight">@startOffset</code>, <code class="highlight">@endOffset</code>).</p> <li data-md> <p><code class="highlight">@startOffset</code> and <code class="highlight">@duration</code> are present, the interval is defined by [<code class="highlight">@startOffset</code>, <code class="highlight">@startOffset</code>+<code class="highlight">@duration</code>).</p> </ul> <p>If none of these combinations is specified, then the encryptor is determining the key period boundaries internally, and other components do not need to be aware of them. In this case, the key periods are referenced simply by a sequence number (<code class="highlight">@index</code>) or a string index (<code class="highlight">@label</code>). An example of this use of <code class="highlight">@index</code> would be an encryptor which rotates the keys once an hour, and not necessarily at specific times.</p> <figure> <img src="Images/Schema-ContentKeyPeriod.png"> <figcaption>ContentKeyPeriod element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.15" id="schema-datamodel-contentkeyusagerulelist"><span class="secno">7.4.15. </span><span class="content"><code class="highlight">ContentKeyUsageRuleList</code> Element</span><a class="self-link" href="#schema-datamodel-contentkeyusagerulelist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (O, xs:integer)</code> <dd data-md> <p>Matches the <code class="highlight">@updateVersion</code> attribute of the <code class="highlight">UpdateHistoryItem</code> element providing details on when this element was added or updated.</p> <dt data-md><code class="highlight">ContentKeyUsageRule (1...N, cpix:ContentKeyUsageRule)</code> <dd data-md> <p>A rule which defines a Content Key Context.</p> </dl> <figure> <img src="Images/Schema-ContentKeyUsageRuleList.png"> <figcaption>ContentKeyUsageRuleList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.16" id="schema-datamodel-contentkeyusagerule"><span class="secno">7.4.16. </span><span class="content"><code class="highlight">ContentKeyUsageRule</code> Element</span><a class="self-link" href="#schema-datamodel-contentkeyusagerule"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@kid (M, cpix:UUIDType)</code> <dd data-md> <p>Matches the <code class="highlight">@kid</code> attribute of the <code class="highlight">ContentKey</code> this element references.</p> <dd data-md> <p>In hierarchical key scenarios, this shall reference a leaf key, not a root key.</p> <dt data-md><code class="highlight">@intendedTrackType (O, xs:string)</code> <dd data-md> <p>Specifies the type of media track which corresponds to the streams which match the rules defined in this element.</p> <dd data-md> <p>Examples of types for the media track might be UHD, UHD+HFR. See <a href="#schema-datamodel-usagerulefilter-labelfilter">�/ 7.4.17.3 LabelFilter Element</a> for more details.</p> <dt data-md><code class="highlight">KeyPeriodFilter (0...N, cpix:KeyPeriodFilter)</code> <dd data-md> <p>Defines a period of time constraints for the Content Key Context.</p> <dd data-md> <p>This filter links <code class="highlight">ContentKey</code> and <code class="highlight">ContentKeyPeriod</code> elements.</p> <dt data-md><code class="highlight">LabelFilter (0...N, cpix:LabelFilter)</code> <dd data-md> <p>Defines a label association for the Content Key Context.</p> <dt data-md><code class="highlight">VideoFilter (0...N, cpix:VideoFilter)</code> <dd data-md> <p>Defines video constraints to be associated with the Content Key Context.</p> <dd data-md> <p>This filter can only be used on media content of type video.</p> <dt data-md><code class="highlight">AudioFilter (0...N, cpix:AudioFilter)</code> <dd data-md> <p>Defines audio constraints to be associated with the Content Key Context.</p> <dd data-md> <p>This filter can only be used on media content of type audio.</p> <dt data-md><code class="highlight">BitrateFilter (0...N, cpix:BitrateFilter)</code> <dd data-md> <p>Defines bitrate constraints to be associated with the Content Key Context.</p> </dl> <p>Additional child elements may be present containing proprietary filters. Such elements shall appear after any elements defined here.</p> <figure> <img src="Images/Schema-ContentKeyUsageRule.png"> <figcaption>ContentKeyUsageRule element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.17" id="schema-datamodel-usagerulefilter"><span class="secno">7.4.17. </span><span class="content">Usage Rules Filters</span><a class="self-link" href="#schema-datamodel-usagerulefilter"></a></h4> <h5 class="heading settled" data-level="7.4.17.1" id="schema-datamodel-usagerulefilter-intro"><span class="secno">7.4.17.1. </span><span class="content">Introduction</span><a class="self-link" href="#schema-datamodel-usagerulefilter-intro"></a></h5> <p>There can be several filters defined within a single <code class="highlight">ContentKeyUsageRule</code>. In this case, all rules apply identically, the entity generating the <code class="highlight">ContentKeyUsageRule</code> element or adding a new rule is responsible for ensuring that they do not contradict each other. A set of rules that would match multiple Content Keys to a single Content Key Context is invalid.</p> <p>If more than one of a particular type of filter (e.g. <code class="highlight">KeyPeriodFilter</code>) is present within a <code class="highlight">ContentKeyUsageRule</code>, then they are first aggregated with a logical OR operator. After that, different types of filters are aggregated with a logical AND operator. For example, a rule that defines a label filter for stream-1, a label filter for steam-2 and a video filter would be matched as (stream-1 OR stream-2) AND video.</p> <p>A scenario where multiple Content Keys can be mapped to a single Content Key Context shall be considered invalid. A CPIX document shall always match exactly zero or one Content Keys to any Content Key Context.</p> <p>A usage rule shall be considered unusable if it contains a child element whose meaning is unknown (i.e. a filter of an unknown type) or which cannot be processed for any other reason (e.g. <code class="highlight">@minPixels</code> in the <code class="highlight">VideoFilter</code> element is defined but the implementation does not know the pixel count of the video samples). An entity interpreting the <code class="highlight">ContentKeyUsageRule</code> element shall not perform Content Key(s) mapping to Content Key Contexts if any unusable usage rules exist. An entity that is not interpreting the <code class="highlight">ContentKeyUsageRule</code> element (doing, for example, only storage of the CPIX document for latter distribution to another entity) can perform any processing on the document.</p> <p>Processing of the Content Key(s) referenced by any unusable usage rules shall not be performed. The usable part of the document can be processed normally.</p> <p>There can be many different sources for defining usage rules, for example, they can be the result of a right holder requirement or a decision to encrypt separately SD, HD and UHD tracks. The CPIX document does not keep track of the source of these rules, it only defines how to maps Content Keys to tracks.</p> <h5 class="heading settled" data-level="7.4.17.2" id="schema-datamodel-usagerulefilter-keyperiodfilter"><span class="secno">7.4.17.2. </span><span class="content"><code class="highlight">KeyPeriodFilter</code> Element</span><a class="self-link" href="#schema-datamodel-usagerulefilter-keyperiodfilter"></a></h5> <dl> <dt data-md><code class="highlight">@periodId (M, xs:IDREF)</code> <dd data-md> <p>This references a <code class="highlight">ContentKeyPeriod</code> element by <code class="highlight">@id</code>. The filter will only match samples that belong to the referenced key period.</p> </dl> <figure> <img src="Images/Schema-KeyPeriodFilter.png"> <figcaption>KeyPeriodFilter element.</figcaption> </figure> <h5 class="heading settled" data-level="7.4.17.3" id="schema-datamodel-usagerulefilter-labelfilter"><span class="secno">7.4.17.3. </span><span class="content"><code class="highlight">LabelFilter</code> Element</span><a class="self-link" href="#schema-datamodel-usagerulefilter-labelfilter"></a></h5> <dl> <dt data-md><code class="highlight">@label (M, xs:string)</code> <dd data-md> <p>The filter will only match samples that carry a matching label. The exact meaning of labels is implementation-defined and shall be agreed upon in advance by the producer and consumer of the CPIX document.</p> </dl> <figure> <img src="Images/Schema-LabelFilter.png"> <figcaption>LabelFilter element.</figcaption> </figure> <p>The <code class="highlight">@label</code> attribute is meant for triggering a particular <code class="highlight">ContentKeyUsageRule</code> by using pre-agreed upon label strings. Its value may or may not correspond to media track types. One example is a label such as UHD that can be used to match the corresponding <code class="highlight">ContentKeyUsageRule</code> element when used as an input or selector for a content encryptor, media packager, MPD generator or license service to select a specific Content Key, populate the <code class="highlight">ContentProtection</code> element, or include the corresponding key in a content license. Another example is if there is a previous agreement defined outside of a CPIX document that "blue tracks" are encrypted with the Content Key 1234 and "green tracks" are encrypted with the Content Key 5678. The labels can be used in this case to identify the suitable tracks (without expressing the specifics of the agreement itself).</p> <p>In contrast, the <code class="highlight">@intendedTrackType</code> attribute of <code class="highlight">ContentKeyUsageRule</code> is used to assign a track type to the media streams which match the filters. The value of the string may not be pre-agreed between the various entities making use of the CPIX document. Said differently, the <code class="highlight">@intendedTrackType</code> attribute is a metadata that states business logic. For example, a rule can be that all low resolutions streams are encrypted with the same Content Key. The value lowRes matches this rule. It has no function in defining what Content Key are matched to what tracks, it simply acts as a label to allow business logic to say authorize the use of lowRes Content Key and then a CPIX processor can find the rules that matches the right Content Keys for lowRes and thereby associated with low resolution tracks.</p> <p>If a specific key is to be used for more than one type of track (this is not recommended), then there ought to be multiple <code class="highlight">ContentKeyUsageRule</code> elements, one for each track type, even if they all reference the same Content Key with the same <code class="highlight">@kid</code>.</p> <h5 class="heading settled" data-level="7.4.17.4" id="schema-datamodel-usagerulefilter-videofilter"><span class="secno">7.4.17.4. </span><span class="content"><code class="highlight">VideoFilter</code> Element</span><a class="self-link" href="#schema-datamodel-usagerulefilter-videofilter"></a></h5> <p>If present, even without any attributes, the filter will only match video samples.</p> <dl> <dt data-md><code class="highlight">@minPixels (OD, xs:integer)</code> <dd data-md> <p>The filter will only match video samples that contain at least this number of pixels (encoded width x height before considering pixel/sample aspect ratio). The default value is 0 (zero).</p> <dt data-md><code class="highlight">@maxPixels (OD, xs:integer)</code> <dd data-md> <p>The filter will not match video samples that contain more than this number of pixels (encoded width x height before considering pixel/sample aspect ratio). The default value is MAX_UINT32.</p> <dt data-md><code class="highlight">@hdr (O, xs:boolean)</code> <dd data-md> <p>Boolean value indicating whether the matching video stream is encoded in HDR.</p> <dt data-md><code class="highlight">@wcg (O, xs:boolean)</code> <dd data-md> <p>Boolean value indicating whether the matching video stream is encoded in WCG.</p> <dt data-md><code class="highlight">@minFps (O, xs:integer)</code> <dd data-md> <p>Minimum nominal number of frames per second for the video stream. For interlaced video, this is half the number of fields per second.</p> <dt data-md><code class="highlight">@maxFps (O, xs:integer)</code> <dd data-md> <p>Maximum nominal number of frames per second for the video stream. For interlaced video, this is half the number of fields per second.</p> </dl> <p>When <code class="highlight">@minPixels</code> and <code class="highlight">@maxPixels</code> are present, the interval is defined by [<code class="highlight">@minPixels</code>, <code class="highlight">@maxPixels</code>], meaning that the filter is used for content with video samples that contain <code class="highlight">@minPixels</code> pixels and is used for content with video samples that contain <code class="highlight">@maxPixels</code> pixels.</p> <p>When <code class="highlight">@minFps</code> and <code class="highlight">@maxFps</code> are present, the interval is defined by (<code class="highlight">@minFps</code>, <code class="highlight">@maxFps</code>], meaning that the filter is not used for content with nominal FPS equal to <code class="highlight">@minFps</code> but is used for content with nominal FPS equal to <code class="highlight">@maxFps</code>.</p> <figure> <img src="Images/Schema-VideoFilter.png"> <figcaption>VideoFilter element.</figcaption> </figure> <h5 class="heading settled" data-level="7.4.17.5" id="schema-datamodel-usagerulefilter-audiofilter"><span class="secno">7.4.17.5. </span><span class="content"><code class="highlight">AudioFilter</code> Element</span><a class="self-link" href="#schema-datamodel-usagerulefilter-audiofilter"></a></h5> <p>If present, even without any attributes, the filter will only match audio samples.</p> <dl> <dt data-md><code class="highlight">@minChannels (OD, xs:integer)</code> <dd data-md> <p>The filter will only match audio samples that contain at least this number of channels. The default value is 0 (zero).</p> <dt data-md><code class="highlight">@maxChannels (OD, xs:integer)</code> <dd data-md> <p>The filter will not match audio samples that contain more than this number of channels. The default value is MAX_UINT32.</p> </dl> <p>When <code class="highlight">@minChannels</code> and <code class="highlight">@maxChannels</code> are present, the interval is defined by [<code class="highlight">@minChannels</code>, <code class="highlight">@maxChannels</code>], meaning that the filter is used for content with audio samples that have <code class="highlight">@minChannels</code> audio channels and is used for content with audio samples that have <code class="highlight">@maxChannels</code> audio channels.</p> <figure> <img src="Images/Schema-AudioFilter.png"> <figcaption>AudioFilter element.</figcaption> </figure> <h5 class="heading settled" data-level="7.4.17.6" id="schema-datamodel-usagerulefilter-bitratefilter"><span class="secno">7.4.17.6. </span><span class="content"><code class="highlight">BitrateFilter</code> Element</span><a class="self-link" href="#schema-datamodel-usagerulefilter-bitratefilter"></a></h5> <dl> <dt data-md><code class="highlight">@minBitrate (OD, xs:integer)</code> <dd data-md> <p>The filter will only match samples from streams with a nominal bitrate in b/s of at least this value. The default value is 0 (zero).</p> <dt data-md><code class="highlight">@maxBitrate (OD, xs:integer)</code> <dd data-md> <p>The filter will not match samples from streams with a nominal bitrate in b/s that exceeds this value. The default value is MAX_UINT32.</p> </dl> <p>At least one of <code class="highlight">@minBitrate</code> and <code class="highlight">@maxBitrate</code> shall be specified.</p> <p>When <code class="highlight">@minBitrate</code> and <code class="highlight">@maxBitrate</code> are present, the interval is defined by [<code class="highlight">@minBitrate</code>, <code class="highlight">@maxBitrate</code>], meaning that the filter is used for content with bitrate of <code class="highlight">@minBitrate</code> and is used for content with bitrate of <code class="highlight">@maxBitrate</code>.</p> <figure> <img src="Images/Schema-BitrateFilter.png"> <figcaption>BitrateFilter element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.18" id="schema-datamodel-updatehistoryitemlist"><span class="secno">7.4.18. </span><span class="content"><code class="highlight">UpdateHistoryItemList</code> Element</span><a class="self-link" href="#schema-datamodel-updatehistoryitemlist"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">UpdateHistoryItem (1...N, cpix:UpdateHistoryItem)</code> <dd data-md> <p>It contains metadata about an update made to the CPIX document. There should be one entry for each instance in which an entity updated the document.</p> </dl> <figure> <img src="Images/Schema-UpdateHistoryItemList.png"> <figcaption>UpdateHistoryItemList element.</figcaption> </figure> <h4 class="heading settled" data-level="7.4.19" id="schema-datamodel-updatehistoryitem"><span class="secno">7.4.19. </span><span class="content"><code class="highlight">UpdateHistoryItem</code> Element</span><a class="self-link" href="#schema-datamodel-updatehistoryitem"></a></h4> <dl> <dt data-md><code class="highlight">@id (O, xs:ID)</code> <dd data-md> <p>An identifier for the element. It is recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@updateVersion (M, xs:integer)</code> <dd data-md> <p>The is the ID referenced by other elements in the document. It is strongly recommended to use an identifier that is unique within the scope in which this CPIX document is published.</p> <dt data-md><code class="highlight">@index (M, xs:string)</code> <dd data-md> <p>This is the version number for the document update. Each <code class="highlight">UpdateHistoryItem</code> element contains a unique value for this attribute. It is a monotonically increasing number, starting at value 1.</p> <dt data-md><code class="highlight">@source (M, xs:string)</code> <dd data-md> <p>This is the identifier for the entity which performed the document update.</p> <dt data-md><code class="highlight">@date (M, xs:dateTime)</code> <dd data-md> <p>This is the date and time when the document update was performed.</p> </dl> <figure> <img src="Images/Schema-UpdateHistoryItem.png"> <figcaption>UpdateHistoryItem element.</figcaption> </figure> <h2 class="heading settled" data-level="8" id="keys"><span class="secno">8. </span><span class="content">Key Management</span><a class="self-link" href="#keys"></a></h2> <h3 class="heading settled" data-level="8.1" id="keys-enc"><span class="secno">8.1. </span><span class="content">Key Encryption and Authentication in the CPIX Document</span><a class="self-link" href="#keys-enc"></a></h3> <h4 class="heading settled" data-level="8.1.1" id="keys-enc-intro"><span class="secno">8.1.1. </span><span class="content">Introduction</span><a class="self-link" href="#keys-enc-intro"></a></h4> <p>The CPIX document allows exchanging Content Keys in the clear but this is not a recommended method as it relies on the security of the communication mechanism used to deliver the CPIX document to the recipients, which may not be sufficient to adequately protect the Content Keys.</p> <p>Content Keys can be delivered encrypted within the document itself and in this case, a multi-level structure of encryption keys is used for an efficient encryption avoiding duplication of encrypted content and expensive encryption methods. This clause describes the mechanism that shall be used when encryption and authentication of the Content Keys in the document is used.</p> <h4 class="heading settled" data-level="8.1.2" id="keys-enc-keytypes"><span class="secno">8.1.2. </span><span class="content">Encryption</span><a class="self-link" href="#keys-enc-keytypes"></a></h4> <p>The document contains the following keys for encrypting Content Keys:</p> <dl> <dt data-md>Content Keys <dd data-md> <p>Each <code class="highlight">ContentKey</code> element contains one Content Key that is used for encrypting an asset or crypto period of an asset or that acts as a dependency for the use of other Content Keys (when a key hierarchy is used). Typically, for Common Encryption as supported in <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a>, these keys are 128-bit keys used with the AES cipher.</p> <dt data-md>Document Keys <dd data-md> <p>For every CPIX document, one or several Document Keys may be created. It is used for encrypting Content Keys. These Document Keys are 256-bit key and the encryption algorithm used for encrypting every Content Key is AES. These are part of <code class="highlight">DeliveryData</code> elements. These are encrypted in the document, using the public key of recipients.</p> <dt data-md>Delivery Keys <dd data-md> <p>Each <code class="highlight">DeliveryData</code> element identifies a Delivery Key, which is a public key from a key pair owned by the intended recipient. The Delivery Key is identified in the <code class="highlight">DeliveryData</code> element by including the X.509 certificate of the intended recipient. The Delivery Key is used for encrypting Document Keys using an algorithm that is described within the CPIX document, according to <a data-link-type="biblio" href="#biblio-xmlenc-core" title="W3C� Recommendation 11 April 2013: XML Encryption Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, 10 December 2002">[XMLENC-CORE]</a>.</p> </dl> <p>The below figure gives the schema of encryption of the different keys when there are several <code class="highlight">DeliveryData</code> elements, one <code class="highlight">DocumentKey</code>element and several <code class="highlight">ContentKey</code> elements. The Document Key allows reducing the numbers of <code class="highlight">ContentKey</code> elements as the Content Key they contain are all encrypted by the same Document Key.</p> <figure> <img src="Images/Diagram-EncryptionOneDocumentKey.png"> <figcaption>Encryption relationships within the CPIX document with one Document Key.</figcaption> </figure> <p>The below figure gives the schema of encryption of the different keys when there are several <code class="highlight">DeliveryData</code> elements, several <code class="highlight">DocumentKey</code> elements and several <code class="highlight">ContentKey</code> elements. In this example, the recipient identified in <code class="highlight">DeliveryData_2</code> is entitled to access a subset of the Content Keys that are in the CPIX document while the recipient identified in <code class="highlight">DeliveryData_1</code> is entitled to access another subset of the Content Keys.</p> <figure> <img src="Images/Diagram-EncryptionSeveralDocumentKeys.png"> <figcaption>Encryption relationships within the CPIX document with several Document Keys.</figcaption> </figure> <h4 class="heading settled" data-level="8.1.3" id="keys-enc-mac"><span class="secno">8.1.3. </span><span class="content">Authenticated Encryption</span><a class="self-link" href="#keys-enc-mac"></a></h4> <p>The document contains the following key for authenticating keys:</p> <dl> <dt data-md>MAC Key <dd data-md> <p>For every CPIX document, a MAC Key may be created. It is used to calculate the MAC of every encrypted Content Key. The <code class="highlight">DeliveryData</code> element identifies the MAC algorithm and provides the MAC Key, encrypted with the Delivery Key, for each recipient.</p> </dl> <p>For authenticated encryption of Content Keys, every encrypted Content Key shall have a MAC value and it shall be verified before attempting to decrypt any encrypted Content Key. The purpose of the MAC is to protect against cryptographic vulnerabilities in the receiving application; it is not used as a general-purpose authentication mechanism.</p> <p>The MAC is calculated over the data in the <code class="highlight">CipherValue</code> element (the concatenated IV and encrypted Content Key) and stored in the <code class="highlight">ValueMac</code> element under the Secret element for each encrypted Content Key.</p> <h4 class="heading settled" data-level="8.1.4" id="keys-enc-signatures"><span class="secno">8.1.4. </span><span class="content">Digital Signature</span><a class="self-link" href="#keys-enc-signatures"></a></h4> <p>Every element in the document that has an <code class="highlight">@id</code> attribute can be signed according to <a data-link-type="biblio" href="#biblio-xmldsig-core" title="W3C� Recommendation 11 April 2013: XML Signature Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, David Solo, et al. (Second Edition), 10 June 2008">[XMLDSIG-CORE]</a>. Furthermore, the document (including any other signatures) can be signed as a whole.</p> <p>Upon loading a CPIX document, implementations should verify that signatures are present on entities that are expected to be signed and verify all digital signatures that are present. Implementations should refuse to process a document if expected signatures are missing or if the signatures cannot be verified or if the signers are not trusted as authoritative sources for the signed data.</p> <p>Implementations should sign any elements that recipients wish to authenticate. Note that modifying any signed data will require any signatures on the data to be removed and/or re-applied. This requires the appropriate consideration and trust model design in content processing workflow creation (out of scope of this specification).</p> <h4 class="heading settled" data-level="8.1.5" id="keys-enc-algorithms"><span class="secno">8.1.5. </span><span class="content">Mandatory Algorithms</span><a class="self-link" href="#keys-enc-algorithms"></a></h4> <p>The following table gives the identification of the algorithms that shall be used for encryption, signature, MAC creation.</p> <table class="def"> <tbody> <tr> <th>Usage <th>Algorithm <tr> <td>Content Key wrapping <td><code class="highlight">AES256-CBC with PKCS #7 padding</code> <tr> <td>Encrypted key MAC <td><code class="highlight">HMAC-SHA512</code> <tr> <td>Document Key wrapping <td><code class="highlight">RSA-OAEP-MGF1-SHA1</code> <tr> <td>Digital signature <td><code class="highlight">RSASSA-PKCS1-v1_5</code> <tr> <td>Digital signature digest <td><code class="highlight">SHA-512</code> <tr> <td>Digital signature canonicalization <td><code class="highlight">Canonical XML 1.1 (comments omitted)</code> </table> <p>For RSA, the recommended minimum key size is 3072 bits and is it not recommended to use certificates that are signed using SHA-1.</p> <h3 class="heading settled" data-level="8.2" id="keys-rotation"><span class="secno">8.2. </span><span class="content">Key Rotation Support</span><a class="self-link" href="#keys-rotation"></a></h3> <p>A CPIX document can contain content protection information for multiple crypto-periods, or period of time for content encrypted using key rotation.</p> <p>When content is protected with key rotation, a CPIX document shall contain one or more <code class="highlight">ContentKey</code> elements and one or more <code class="highlight">ContentKeyPeriod</code> elements, one of each per crypto-period which the document covers. Each <code class="highlight">ContentKey</code> element contains the key material for a single crypto-period. The crypto-period itself is identified by a well-formed <code class="highlight">ContentKeyPeriod</code> element as described in <a href="#schema-datamodel-contentkeyperiod">�/ 7.4.14 ContentKeyPeriod Element</a>.</p> <p>Key rotation may be supported in complex workflows, with one entity requesting DRM Signaling for multiple crypto periods, and another entity providing the requested information (keys, DRM system-specific information for the crypto period, etc). Clause 9 of <a data-link-type="biblio" href="#biblio-dashif-iopv5p6" title="Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022">[DASHIF-IOPv5p6]</a> defines three scenarios for key rotation. The decision for encrypting content following one of these scenarios is made, most of the time, by the entity requesting DRM signaling, the entity providing this information is not aware of it. As a consequence, in some cases, the response will include some information that will not be inserted in the MPD (if requested for DASH content). In more details:</p> <dl> <dt data-md>Manifest based key rotation signaling <dd data-md> <p>The entity providing the DRM signaling shall insert the <code class="highlight">PSSH</code> element and the <code class="highlight">ContentProtectionData</code> element under the <code class="highlight">DRMSystem</code> element associated to all content keys. The <code class="highlight">ContentProtectionData</code> element shall be inserted in the MPD under the <code class="highlight">ContentProtection</code> element. The <code class="highlight">PSSH</code> element may be inserted under the <code class="highlight">moov</code> box.</p> <dt data-md>In-band key rotation signaling <dd data-md> <p>The entity providing the DRM signaling shall insert the <code class="highlight">PSSH</code> element and the <code class="highlight">ContentProtectionData</code> element under the <code class="highlight">DRMSystem</code> element associated to all content keys. The <code class="highlight">ContentProtectionData</code> element shall be ignored. The <code class="highlight">PSSH</code> element shall be inserted under the <code class="highlight">moov</code> box and <code class="highlight">moof</code> boxes of the segments that are encrypted by this key.</p> <dt data-md>In-band key hierarchy <dd data-md> <p>CPIX supports expressing two-level key hierarchies, where each leaf key has exactly one root key that is required in order to use the leaf key. Both root keys and leaf keys are represented using <code class="highlight">ContentKey</code> elements, with leaf keys indicated by the presence of a <code class="highlight">@dependsOnKey</code> attribute that references the root key as described in clause <a href="#schema-datamodel-contentkey">�/ 7.4.7 ContentKey Element</a>.</p> <dd data-md> <p>If a CPIX document includes at least one <code class="highlight">ContentKey</code> element that has a <code class="highlight">@dependsOnKey</code> attribute, the content referenced by the <code class="highlight">@contentId</code> attribute is fully protected with key hierarchy. A CPIX document may include <code class="highlight">ContentKey</code> elements for leaf keys only, the referenced root key is then provided in a different document.</p> <dd data-md> <p>When using hierarchical keys, only the leaf keys shall be used to encrypt media content. Therefore, root keys shall not be referenced by any <code class="highlight">ContentKeyUsageRule</code> elements.</p> <dd data-md> <p>The <code class="highlight">PSSH</code> element under the <code class="highlight">DRMSystem</code> element associated to the root key shall be inserted under the <code class="highlight">moov</code> box, while, for the leaf keys, it shall be inserted under the <code class="highlight">moof</code> boxes of the segments that are encrypted by this leaf key. The <code class="highlight">ContentProtectionData</code> element of the <code class="highlight">DRMSystem</code> element associated to the root key shall be inserted in the MPD. The entity providing the signaling uses the presence or not of the <code class="highlight">@dependsOnKey</code> attribute in the <code class="highlight">ContentKey</code> element for knowing what type of signaling it needs to generate for every key.</p> <dd data-md> <p>Note that not all DRM systems support key hierarchy.</p> </dl> <h3 class="heading settled" data-level="8.3" id="keys-encryptionScheme"><span class="secno">8.3. </span><span class="content">Content Keys with Several Protection Encryption Schemes</span><a class="self-link" href="#keys-encryptionScheme"></a></h3> <p>In <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a>, several protection schemes that are not interoperable are defined. This means that several encrypted versions for the same content in the clear are created if the targeted devices support one or another protection scheme. While it may not be recommended, it is possible to use the same Content Keys when encrypting these different versions. In term of CPIX document, this means that several documents need to be created, these documents will differ on the <code class="highlight">@commonEncryptionScheme</code> attribute under the <code class="highlight">ContentKey</code> element which will take a different value depending on the protection schemes. Note that depending on the DRM, some elements under the <code class="highlight">DRMSystem</code> element may also be different.</p> <h2 class="heading settled" data-level="9" id="best-practices"><span class="secno">9. </span><span class="content">CPIX Documents Best Practices</span><a class="self-link" href="#best-practices"></a></h2> <p>This clause provides best pactices for CPIX documents for some use cases. It provides the minimum set of elements and attributes to expect for these use cases.</p> <p>For the sake of simplicity, best pactices are considering three widely deployed and supported DRMs, namely, FairPlay, PlayReady and Widevine. Each DRM comes with its own signaling and some constraints. For example, it is very unlikely that FairPlay DRM signaling is needed for a content key with a <code class="highlight">@commonEncryptionScheme</code> value equals to <code class="highlight">cenc</code>. PlayReady signaling is defined on this <a href="https://learn.microsoft.com/en-gb/playready/packaging/mp4-based-formats-supported-by-playready-clients?tabs=case1">page</a>, offering some flexibiliby but not supporting all encrpytion modes defined in <a data-link-type="biblio" href="#biblio-mpegcenc" title="ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016">[MPEGCENC]</a>.</p> <p>Disclaimer: This clause is not taking any commitment on the exact set of features supported by every DRM. In addition, this can evolve over time.</p> <p>These best practices can be found on <a href="https://github.com/Dash-Industry-Forum/CPIX">GitHub</a> and are:</p> <dl> <dt data-md>An asset with one content key (<code class="highlight">OneContentKey.xml</code>) <dd data-md> <p>One content key is provided in the clear. This key has a <code class="highlight">@commonEncryptionScheme</code> value equals to <code class="highlight">cbcs</code>. HDCP data are attached to this content key in the form of an <code class="highlight">HDCPData</code>element. <code class="highlight">DRMSystem</code> elements include the expected robustness level, expressed in the terms defined by each DRM.</p> <dt data-md>An asset with multiples content keys (<code class="highlight">KPTIntentedTrackType.xml</code>, <code class="highlight">KPTLabelFilter.xml</code>) <dd data-md> <p>Two content keys are provided in the clear. They both have a <code class="highlight">@commonEncryptionScheme</code> value equals to <code class="highlight">cenc</code>. Each DRMSystem element has a <code class="highlight">@robustness</code> attribute defining the expected robustness level for this DRM system for using the content key.</p> <dd data-md> <p>In the first file, each content key is associated with a ContentKeyUsageRule element that contains an <code class="highlight">@intendedTrackType</code> attribute, hence associating each key to a list of tracks associated to these values. In the second file, the exact same assocation is expressed using a <code class="highlight">Label</code> filter.</p> <dt data-md>An asset with multiples content keys encrypted (<code class="highlight">KPTIntentedTrackTypeEncrypted.xml</code>) <dd data-md> <p>This is a continuation of one of the previous file where the content key are both encryped with one document key for one recipent that is described under a <code class="highlight">DeliveryData</code> element.</p> <dt data-md>An Asset with multiples content keys signed (<code class="highlight">KPTIntentedTrackTypeSigned.xml</code>) <dd data-md> <p>Another continuation that describes the possiblity to sign some elements of the CPIX document. In this case, one may want to ensure that the <code class="highlight">ContentKeyList</code> element is not modifed so that it is alway possible to decrypt the content ideentified by the <code class="highlight">@contentId</code> attribute that is part of the <code class="highlight">CPIX</code> element. Note that, in this file, the content keys are not encrypted, nothing prevents to also encrypt them and to sign the corresponding <code class="highlight">ContentKeyList</code> element.</p> <dt data-md>An asset with key rotation (<code class="highlight">KeyRotationIndex.xml</code>, <code class="highlight">KeyRotationDate.xml</code>, <code class="highlight">KeyHierarchy.xml</code>) <dd data-md> <p>As described in clause <a href="#keys-rotation">�/ 8.2 Key Rotation Support</a>, there are several mechanisms for enabling key rotation, hence, in case of DASH content, this means that the MPD is different. The CPIX document may then contain different information depending on the mode used. It is up to the receiveing entity to extract the relevant information and create a functional MPD.</p> <dd data-md> <p>Within a CPIX document, the simplest model includes a <code class="highlight">ContentKeyPeriod</code> element and its associated <code class="highlight">KeyPeriodFilter</code> element. This is shown in the first and second files, using <code class="highlight">@index</code> in the first file and <code class="highlight">@start</code>, <code class="highlight">@end</code>in the second file. The DRM signaling data includes all information and it is the responsibility of the entity generating the MDP to extract the relevant information depending on the MDP to be generated as explained in clause <a href="#keys-rotation">�/ 8.2 Key Rotation Support</a>.</p> <dd data-md> <p>The third file include an example with key herarchy, where all signaling for HDCP, robustness level are attached to the root key only. The <code class="highlight">KeyPeriodFilter</code> elements are attached to the leaf keys. Note that the <code class="highlight">PSSH</code> and <code class="highlight">ContentProtectionData</code> elements contains dummy data in this file.</p> <dt data-md>An asset with key rotation and multiples content keys (<code class="highlight">KeyRotationAndKPT.xml</code> and <code class="highlight">KeyHierarchyAndKPT.xml</code>) <dd data-md> <p>Associating key per track and key rotations, these files show the possibilities of the signaling in these cases. Key rotation can be also with key hierarchy, hence the second file for this example. Associating these funtionalities show how filters can be described in one <code class="highlight">ContentKeyUsageRule</code> element.</p> </dl> <h2 class="heading settled" data-level="10" id="abbreviations"><span class="secno">10. </span><span class="content">Abbreviations</span><a class="self-link" href="#abbreviations"></a></h2> <dl> <dt data-md>AES <dd data-md> <p>Advanced Encryption Standard</p> <dt data-md>BMFF <dd data-md> <p>Base Media File Format</p> <dt data-md>CBC <dd data-md> <p>Cypher Block Chaining</p> <dt data-md>CDN <dd data-md> <p>Content Delivery Network</p> <dt data-md>CMS <dd data-md> <p>Content Management System</p> <dt data-md>CPIX <dd data-md> <p>Content Protection Information eXchange</p> <dt data-md>DASH <dd data-md> <p>Dynamic Adaptive Streaming over HTTP</p> <dt data-md>DRM <dd data-md> <p>Digital Right Management</p> <dt data-md>EPG <dd data-md> <p>Electronic Program Guide</p> <dt data-md>FPS <dd data-md> <p>Frames Per Second</p> <dt data-md>HD <dd data-md> <p>High Definition</p> <dt data-md>HDCP <dd data-md> <p>High-bandwidth Digital Content Protection</p> <dt data-md>HDR <dd data-md> <p>High Dynamic Range</p> <dt data-md>HLS <dd data-md> <p>HTTP Live Streaming</p> <dt data-md>ISO <dd data-md> <p>International Organization for Standardization</p> <dt data-md>IV <dd data-md> <p>Initialization Vector</p> <dt data-md>KID <dd data-md> <p>Key IDentifier</p> <dt data-md>MAC <dd data-md> <p>Message Authentication Code</p> <dt data-md>MPD <dd data-md> <p>Media Presentation Description</p> <dt data-md>OD <dd data-md> <p>Optional with Default value</p> <dt data-md>PKCS <dd data-md> <p>Public Key Cryptography Standards</p> <dt data-md>PSSH <dd data-md> <p>Protection System Specific Header</p> <dt data-md>RSA <dd data-md> <p>Rivest, Shamir, &amp; Adleman</p> <dt data-md>SD <dd data-md> <p>Standard Definition</p> <dt data-md>SHA <dd data-md> <p>Secure Hash Algorithm</p> <dt data-md>UHD <dd data-md> <p>Ultra High Definition</p> <dt data-md>URI <dd data-md> <p>Uniform Ressource Identifier</p> <dt data-md>UUID <dd data-md> <p>Universally Unique IDentifier</p> <dt data-md>VOD <dd data-md> <p>Video On Demand</p> <dt data-md>WCG <dd data-md> <p>Wide Color Gamut</p> <dt data-md>XML <dd data-md> <p>eXtensible Markup Language</p> <dt data-md>XSD <dd data-md> <p>XML Schema Definition</p> </dl> <script async src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/MathJax.js?config=default" type="text/javascript"></script> </main> <script> (function() { "use strict"; var collapseSidebarText = '<span aria-hidden="true">�!</span> ' + '<span>Collapse Sidebar</span>'; var expandSidebarText = '<span aria-hidden="true">�!</span> ' + '<span>Pop Out Sidebar</span>'; var tocJumpText = '<span aria-hidden="true">�!</span> ' + '<span>Jump to Table of Contents</span>'; var sidebarMedia = window.matchMedia('screen and (min-width: 78em)'); var autoToggle = function(e){ toggleSidebar(e.matches) }; if(sidebarMedia.addListener) { sidebarMedia.addListener(autoToggle); } function toggleSidebar(on) { if (on == undefined) { on = !document.body.classList.contains('toc-sidebar'); } /* Don't scroll to compensate for the ToC if we're above it already. */ var headY = 0; var head = document.querySelector('.head'); if (head) { // terrible approx of "top of ToC" headY += head.offsetTop + head.offsetHeight; } var skipScroll = window.scrollY < headY; var toggle = document.getElementById('toc-toggle'); var tocNav = document.getElementById('toc'); if (on) { var tocHeight = tocNav.offsetHeight; document.body.classList.add('toc-sidebar'); document.body.classList.remove('toc-inline'); toggle.innerHTML = collapseSidebarText; if (!skipScroll) { window.scrollBy(0, 0 - tocHeight); } tocNav.focus(); sidebarMedia.addListener(autoToggle); // auto-collapse when out of room } else { document.body.classList.add('toc-inline'); document.body.classList.remove('toc-sidebar'); toggle.innerHTML = expandSidebarText; if (!skipScroll) { window.scrollBy(0, tocNav.offsetHeight); } if (toggle.matches(':hover')) { /* Unfocus button when not using keyboard navigation, because I don't know where else to send the focus. */ toggle.blur(); } } } function createSidebarToggle() { /* Create the sidebar toggle in JS; it shouldn't exist when JS is off. */ var toggle = document.createElement('a'); /* This should probably be a button, but appearance isn't standards-track.*/ toggle.id = 'toc-toggle'; toggle.class = 'toc-toggle'; toggle.href = '#toc'; toggle.innerHTML = collapseSidebarText; sidebarMedia.addListener(autoToggle); var toggler = function(e) { e.preventDefault(); sidebarMedia.removeListener(autoToggle); // persist explicit off states toggleSidebar(); return false; } toggle.addEventListener('click', toggler, false); /* Get <nav id=toc-nav>, or make it if we don't have one. */ var tocNav = document.getElementById('toc-nav'); if (!tocNav) { tocNav = document.createElement('p'); tocNav.id = 'toc-nav'; /* Prepend for better keyboard navigation */ document.body.insertBefore(tocNav, document.body.firstChild); } /* While we're at it, make sure we have a Jump to Toc link. */ var tocJump = document.getElementById('toc-jump'); if (!tocJump) { tocJump = document.createElement('a'); tocJump.id = 'toc-jump'; tocJump.href = '#toc'; tocJump.innerHTML = tocJumpText; tocNav.appendChild(tocJump); } tocNav.appendChild(toggle); } var toc = document.getElementById('toc'); if (toc) { createSidebarToggle(); toggleSidebar(sidebarMedia.matches); /* If the sidebar has been manually opened and is currently overlaying the text (window too small for the MQ to add the margin to body), then auto-close the sidebar once you click on something in there. */ toc.addEventListener('click', function(e) { if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) { toggleSidebar(false); } }, false); } else { console.warn("Can't find Table of Contents. Please use <nav id='toc'> around the ToC."); } /* Wrap tables in case they overflow */ var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index'); var numTables = tables.length; for (var i = 0; i < numTables; i++) { var table = tables[i]; var wrapper = document.createElement('div'); wrapper.className = 'overlarge'; table.parentNode.insertBefore(wrapper, table); wrapper.appendChild(table); } })(); </script> <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2> <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3> <dl> <dt id="biblio-dashif-iopv5p6">[DASHIF-IOPv5p6] <dd><a href="https://dashif.org/guidelines/iop-v5/iop-v5/"><cite>Guidelines for Implementation: DASH-IF Interoperability Points; Part 6 Content Protection, version 5.0, January 2022</cite></a>. URL: <a href="https://dashif.org/guidelines/iop-v5/iop-v5/">https://dashif.org/guidelines/iop-v5/iop-v5/</a> <dt id="biblio-hls">[HLS] <dd><a href="https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/"><cite>R. Pantos. HTTP Live Streaming 2nd Edition. Internet Draft</cite></a>. URL: <a href="https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/">https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/</a> <dt id="biblio-mpegcenc">[MPEGCENC] <dd><a href="https://www.iso.org/standard/68042.html"><cite>ISO/IEC 23001-7:2016: Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files, February 2016</cite></a>. URL: <a href="https://www.iso.org/standard/68042.html">https://www.iso.org/standard/68042.html</a> <dt id="biblio-rfc6030">[RFC6030] <dd><a href="https://www.rfc-editor.org/rfc/rfc6030"><cite>IETF RFC 6030: Portable Symmetric Key Container (PSKC), October 2010</cite></a>. URL: <a href="https://www.rfc-editor.org/rfc/rfc6030">https://www.rfc-editor.org/rfc/rfc6030</a> <dt id="biblio-xmldsig-core">[XMLDSIG-CORE] <dd><a href="https://www.w3.org/TR/xmldsig-core/"><cite>W3C� Recommendation 11 April 2013: XML Signature Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, David Solo, et al. (Second Edition), 10 June 2008</cite></a>. URL: <a href="https://www.w3.org/TR/xmldsig-core/">https://www.w3.org/TR/xmldsig-core/</a> <dt id="biblio-xmlenc-core">[XMLENC-CORE] <dd><a href="https://www.w3.org/TR/xmlenc-core/"><cite>W3C� Recommendation 11 April 2013: XML Encryption Syntax and Processing Version 1.1, Donald Eastlake, Joseph Reagle, 10 December 2002</cite></a>. URL: <a href="https://www.w3.org/TR/xmlenc-core/">https://www.w3.org/TR/xmlenc-core/</a> <dt id="biblio-xmlschema11-2">[XMLSCHEMA11-2] <dd><a href="https://www.w3.org/TR/xmlschema11-2/"><cite>W3C� Recommendation 5 April 2012: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, David Peterson et al</cite></a>. URL: <a href="https://www.w3.org/TR/xmlschema11-2/">https://www.w3.org/TR/xmlschema11-2/</a> </dl>