# SPEKE API v2
<a name="the-speke-api-v2"></a>

This is the REST API for Secure Packager and Encoder Key Exchange (SPEKE) v2. Use this specification to provide DRM copyright protection for customers who use encryption. To be SPEKE-compliant, your DRM key provider must expose the REST API described in this specification. The encryptor makes API calls to your key provider.

**Note**  
The code examples in this specification are for illustration purposes only. You can’t run the examples because they aren’t part of a complete SPEKE implementation.

SPEKE uses the DASH Industry Forum Content Protection Information Exchange Format (DASH-IF-CPIX) data structure definition for key exchange, with some restrictions. DASH-IF-CPIX defines a schema to provide an extensible, multi-DRM exchange from the DRM platform to the encryptor. This enables content encryption for all adaptive bitrate packaging formats at the time of content compression and packaging. Adaptive bitrate packaging formats include HLS, DASH, and MSS.

Starting with its version 2.0, SPEKE is aligned on a specific CPIX version:

On the SPEKE side, this is enforced through the use of the `X-Speke-Version` HTTP header, and on the CPIX side through the use of the `CPIX@version` attribute. A lack of these elements in the requests is typical of SPEKE v1 legacy workflows. In SPEKE v2 workflows, the key provider is expected to process CPIX documents only if it supports both version parameters.

For detailed information about the exchange format, see the DASH Industry Forum [CPIX 2.3 specification](https://dashif.org/docs/CPIX2.3/Cpix.html).

Overall, SPEKE v2.0 brings the following evolutions compared to SPEKE v1.0:
+ All tags from the SPEKE XML namespace are deprecated in favor of equivalent tags in the CPIX XML namespace
+  `SPEKE:ProtectionHeader` is deprecated and replaced by `CPIX:DRMSystem.SmoothStreamingProtectionHeaderData` 
+  `CPIX:URIExtXKey`, `SPEKE:KeyFormat` and `SPEKE:KeyFormatVersions` are deprecated and replaced by `CPIX:DRMSystem.HLSSignalingData` 
+  `CPIX@id` is replaced by `CPIX@contentId` 
+ New mandatory CPIX attributes: `CPIX@version`, `ContentKey@commonEncryptionScheme` 
+ New optional CPIX element: `DRMSystem.ContentProtectionData` 
+ Support for multiple content keys
+ Cross-versioning mechanism between SPEKE and CPIX
+ HTTP headers evolution: new `X-Speke-Version` header, `Speke-User-Agent` header renamed into `X-Speke-User-Agent` 
+ Heartbeat API deprecation

As the SPEKE v1.0 specification stays unchanged, existing implementations don’t need to change to continue supporting SPEKE v1.0 workflows.

**Topics**
+ [SPEKE API v2 - Customizations and constraints to the DASH-IF specification](speke-constraints-v2.md)
+ [SPEKE API v2 - Standard payload components](standard-payload-components-v2.md)
+ [SPEKE API v2 - Encryption contract](encryption-contract-v2.md)
+ [SPEKE API v2 - Live workflow method call examples](live-workflow-methods-v2.md)
+ [SPEKE API v2 - VOD workflow method call examples](vod-workflow-method-v2.md)
+ [SPEKE API v2 - Content key encryption](content-key-encryption-v2.md)
+ [SPEKE API v2 - Overriding the key identifier](kid-override-v2.md)

# SPEKE API v2 - Customizations and constraints to the DASH-IF specification
<a name="speke-constraints-v2"></a>

The DASH Industry Forum [CPIX 2.3 specification](https://dashif.org/docs/CPIX2.3/Cpix.html) supports a number of use cases and topologies. The SPEKE API v2.0 specification defines both a CPIX Profile and an API for CPIX. In order to achieve these two goals, it adheres to the CPIX specification with the following customizations and constraints:

**CPIX Profile**
+ SPEKE follows the Encryptor Consumer workflow.
+ For encrypted content keys, SPEKE applies the following restrictions:
  + SPEKE doesn’t support digital signature verification (XMLDSIG) for request or response payloads.
  + SPEKE requires 2048 RSA-based certificates.
+ SPEKE leverages only a subset of CPIX functionalities:
  + SPEKE omits the `UpdateHistoryItemList` functionality. If the list is present in the response, SPEKE ignores it.
  + SPEKE omits the root/leaf key functionality. If the `ContentKey@dependsOnKey` attribute is present in the response, SPEKE ignores it.
  + SPEKE omits the `BitrateFilter` element and the `VideoFilter@wcg` attribute. If these elements or attributes are present in the CPIX payload, SPEKE ignores it.
+ Only the elements or attributes referenced as 'Supported' on the [Standard Payload Components page](standard-payload-components-v2.md) or the [Encryption contract page](encryption-contract-v2.md) can be used in CPIX documents exchanged with SPEKE v2.
+ When included in a CPIX request by the encryptor, all elements and attributes shall carry a valid value in the key provider CPIX response. If not, the encryptor shall stop and throw an error.
+ SPEKE supports key rotation with `KeyPeriodFilter` elements. SPEKE uses only the `ContentKeyPeriod@index` to track the key period.
+ For HLS signaling, multiple `DRMSystem.HLSSignalingData` elements must be used: one with a `DRMSystem.HLSSignalingData@playlist` attribute value of ‘media’, and another one with a `DRMSystem.HLSSignalingData@playlist` attribute value of ‘master’.
+ When requesting keys, the encryptor might use the optional `@explicitIV` attribute on the `ContentKey` element. The key provider can respond with an IV using `@explicitIV`, even if the attribute is not included in the request.
+ The encryptor creates the key identifier (`KID`), which stays the same for any given content ID and key period. The key provider includes the `KID` in its response to the request document.
+ The encryptor shall include a value for the `CPIX@contentId` attribute. When receiving an empty value for this attribute, the key provider shall return an error with description 'Missing CPIX@contentId'. `CPIX@contentId` value cannot be overriden by the key provider.

   `CPIX@id` value, if not null, shall be ignored by the key provider.
+ The encryptor shall include a value for the `CPIX@version` attribute. When receiving an empty value for this attribute, the key provider shall return an error with description 'Missing CPIX@version'. When receiving a request with an unsupported version, the error description returned by the key provider shall be 'Unsupported CPIX@version'.

   `CPIX@version` value cannot be overriden by the key provider.
+ The encryptor shall include a value for the `ContentKey@commonEncryptionScheme` attribute for each requested key. When receiving an empty value for this attribute, the key provider shall return an error with description 'Missing ContentKey@commonEncryptionScheme for KID `id` '.

  A unique CPIX document cannot mix multiple values for different `ContentKey@commonEncryptionScheme` attributes. When receiving such a combination, the key provider shall return an error with description 'Non compliant ContentKey@commonEncryptionScheme combination'.

  Not all `ContentKey@commonEncryptionScheme` values are compatible with all DRM technologies. When receiving such a combination, the key provider shall return an error with description 'ContentKey@commonEncryptionScheme non compatible with DRMSystem `id` '.

   `ContentKey@commonEncryptionScheme` value cannot be overriden by the key provider.
+ When receiving different values for `DRMSystem@PSSH` and `DRMSystem.ContentProtectionData` innerXML `<pssh>` element in the CPIX response body, the encryptor shall stop and throw an error.

**API for CPIX**
+ The key provider shall include a value for the `X-Speke-User-Agent` HTTP response header.
+ A SPEKE-compliant encryptor acts as a client and sends POST operations to the key provider endpoint.
+ The encryptor shall include a value for the `X-Speke-Version` HTTP request header, with the SPEKE version used with the request, formulated as MajorVersion.MinorVersion, like '2.0' for SPEKE v2.0. If the key provider doesn’t support the SPEKE version used by the encryptor for the current request, the key provider shall return an error with description 'Unsupported SPEKE version' and not try to process the CPIX document on a best effort basis.

  The `X-Speke-Version` header value defined by the encryptor cannot be modified by the key provider in the response to the request.
+ When receiving errors in the response body, the encryptor shall throw an error and not retry the request with a SPEKE v1.0 versioning.

  If the key provider doesn’t return an error but fails to return a CPIX document that includes the mandatory information, the encryptor should stop and throw an error.

The following table summarizes the standard messages that must be returned by the key provider in the body of the message. The HTTP response code in error cases shall be a 4XX or a 5XX, never a 200. The 422 error code can be used for all errors related to SPEKE/CPIX.


| Error case | Error message | 
| --- | --- | 
|  CPIX@contentId is not defined  |  Missing CPIX@contentId  | 
|  CPIX@version is not defined  |  Missing CPIX@version  | 
|  CPIX@version is not supported  |  Unsupported CPIX@version  | 
|  ContentKey@commonEncryptionScheme is not defined  |  Missing ContentKey@commonEncryptionScheme for KID `id` (where `id` equals ContentKey@kid value)  | 
|  Multiple ContentKey@commonEncryptionScheme values used in a single CPIX document  |  Non compliant ContentKey@commonEncryptionScheme combination  | 
|  ContentKey@commonEncryptionScheme is not compatible with DRM technology  |  ContentKey@commonEncryptionScheme non compatible with DRMSystem `id` (where `id` equals DRMSystem@systemId value)  | 
|  X-Speke-Version header value is not a supported SPEKE version  |  Unsupported SPEKE version  | 
|  The encryption contract is malformed  |  Malformed encryption contract  | 
|  The encryption contract contradicts DRM security levels constraints  |  Requested CPIX encryption contract not supported  | 
|  The encryption contract doesn’t include any VideoFilter or AudioFilter element  |  Missing CPIX encryption contract  | 

# SPEKE API v2 - Standard payload components
<a name="standard-payload-components-v2"></a>

Through a single SPEKE request, the encryptor can request multiple content keys, together with the necessary manfest signaling for multiple packaging formats, according to the encryption contract that is defined for a given content.

In order to cover all these aspects, a standard CPIX document is composed of three mandatory list sections, plus an optional list section for live content key rotation.

**<cpix:ContentKeyList> section and top level <cpix:CPIX> element**  
This is a mandatory section, relevant for both Live and VOD streaming, defining the different content keys that need to be used by the encryptor. The `<cpix:ContentKeyList>` element can contain one or several `<cpix:ContentKey>` child elements, each of them describing a distinct content key.

As per the CPIX specification, the possible values of the `ContentKey@commonEncryptionScheme` attribute are defined in the Common encryption in ISO base media file format files specification (ISO/IEC 23001-7:2016):
+ 'cenc': AES-CTR mode full sample and video NAL Subsample encryption
+ 'cbc1': AES-CBC mode full sample and video NAL Subsample encryption
+ 'cens': AES-CTR mode partial video NAL pattern encryption
+ 'cbcs': AES-CBC mode partial video NAL pattern encryption

The following example shows a CPIX document with a single, non encrypted, content key:

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>5dGAgwGuUYu4dHeHtNlxJw==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
	</cpix:ContentKeyList>
	...
</cpix:CPIX>
```

By default, content keys are not encrypted, as in the example below. But the encryption of content keys can be requested by the encryptor through the inclusion of the <cpix:DeliveryDataList> element. Please refer to the Content Key Encryption section for more details.


| Element supported by SPEKE | Mandatory attributes | Optional attributes | Mandatory child elements | Optional child elements | 
| --- | --- | --- | --- | --- | 
|  <cpix:CPIX>  |  contentId, version, xmlns:cpix, xmlns:pskc  |  name, xmlns:enc  |  one <cpix:ContentKeyList>, one <cpix:DRMSystemList>, one <cpix:ContentKeyUsageRuleList>  |  one <cpix:DeliveryDataList>, one <cpix:ContentKeyPeriodList>  | 
|  <cpix:ContentKeyList>  |  -  |  id  |  at least one <cpix:ContentKey>  |  -  | 
|  <cpix:ContentKey>  |  kid, commonEncryptionScheme, Data  |  id, Algorithm, explicitIV  |  one <pskc:Secret>  |  -  | 
|  <pskc:Secret>  |  PlainValue or EncryptedValue  |  ValueMAC  |  -  |  <enc:EncryptionMethod>, <enc:CipherData>  | 

**<cpix:DRMSystemList> section**  
This is a mandatory section, relevant for both Live and VOD streaming, defining the different DRM systems that need to be leveraged together with the content keys.

The following example shows a DRM system list with a single PlayReady DRM system specification:

```
<cpix:DRMSystemList>
	<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
		<cpix:HLSSignalingData playlist="media">HicXmbZ2m[...]4==</cpix:HLSSignalingData>
		<cpix:HLSSignalingData playlist="master">HicXmbZ2m[...]jEi</cpix:HLSSignalingData>
		<cpix:ContentProtectionData>t7WwH24FI[...]YCC</cpix:ContentProtectionData>
		<cpix:PSSH>FFFFanBzc[...]A==</cpix:PSSH>
		<cpix:SmoothStreamingProtectionHeaderData>s5RrJ12HL[...]UBB</cpix:SmoothStreamingProtectionHeaderData>
	</cpix:DRMSystem>
</cpix:DRMSystemList>
```

For a complete list of DRM systemIDs, please refer to the [Content Protection section](https://dashif.org/identifiers/content_protection/) of the DASH-IF Identifiers repository.


| Element supported by SPEKE | Mandatory attributes | Optional attributes | Mandatory child elements | Optional child elements | 
| --- | --- | --- | --- | --- | 
|  <cpix:DRMSystemList>  |  -  |  id  |  at least one <cpix:DRMSystem>  |  -  | 
|  <cpix:DRMSystem>  |  kid, systemId  |  id, name, PSSH  |  -  |  ContentProtectionData, SmoothStreamingProtectionHeaderData, two <cpix:HLSSignalingData> elements with different playlist attribute value  | 

 `DRMSystem@PSSH` is mandatory if ISO-BMFF encapsulation is applied to media segments. `DRMSystem.ContentProtectionData` innerXML `<pssh>` element is leveraged by the encryptor only for manifest signaling purposes.

If `DRMSystem@PSSH` is present and `DRMSystem.ContentProtectionData` contains a innerXML `<pssh>` element, both values shall be identical.

If `DRMSystem` signaling is to be carried in HLS manifests, both a `<cpix:HLSSignalingData playlist="media">` and a `<cpix:HLSSignalingData playlist="master">` elements must be included in the CPIX request and response.

**<cpix:ContentKeyPeriodList> section**  
This is an optional section, relevant only for Live streaming, defining the crypto periods applied to the content.

The `<cpix:ContentKeyPeriodList>` element can contain one or several `<cpix:ContentKeyPeriod>` child elements, each of them describing a distinct crypto period in the live timeline. Using UUIDs as part of the value of the id attribute is a commonly used approach.

```
<cpix:ContentKeyPeriodList>
	<cpix:ContentKeyPeriod id="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f" index="1" />
</cpix:ContentKeyPeriodList>
```


| Element supported by SPEKE | Mandatory attributes | Optional attributes | Mandatory child elements | Optional child elements | 
| --- | --- | --- | --- | --- | 
|  <cpix:ContentKeyPeriodList>  |  -  |  id  |  at least one <cpix:ContentKeyPeriod>  |  -  | 
|  <cpix:ContentKeyPeriod>  |  id, index  |  -  |  -  |  -  | 

If crypto periods are used, the encryption keys also need to be attached to one of the crypto periods in the CPIX document, as shown in the section below.

**<cpix:ContentKeyUsageRuleList> section**  
This is a mandatory section, relevant for both Live and VOD streaming, defining how the different content keys will protect tracks inside the streamset and across the crypto periods.

The <cpix:ContentKeyUsageRuleList> element can contain one or several <cpix:ContentKeyUsageRule> child elements, each of them describing the tracks to which a given content key is applied by the encryptor, potentially during a specific crypto period. At least one <cpix:AudioFilter> or one <cpix:VideoFilter> element is required to be present in a <cpix:ContentKeyUsageRule> element.

The following example shows a simple list with only one rule applying a single content key to all audio and video tracks during a specific crypto period.

```
<cpix:ContentKeyUsageRuleList>
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="ALL">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
		<cpix:VideoFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```


| Element supported by SPEKE | Mandatory attributes | Optional attributes | Mandatory child elements | Optional child elements | 
| --- | --- | --- | --- | --- | 
|  <cpix:ContentKeyUsageRuleList>  |  -  |  id  |  at least one <cpix:ContentKeyUsageRule>  |  -  | 
|  <cpix:ContentKeyUsageRule>  |  kid, intendedTrackType  |  -  |  at least one <cpix:AudioFilter> or one <cpix:VideoFilter> (\$1)  |  <cpix:KeyPeriodFilter>  | 
|  <cpix:KeyPeriodFilter>  |  periodId  |  -  |  -  |  -  | 
|  <cpix:AudioFilter>  |  -  |  minChannels, maxChannels  |  -  |  -  | 
|  <cpix:VideoFilter>  |  -  |  minPixels, maxPixels, hdr, minFps, maxFps  |  -  |  -  | 

 *(\$1) For a detailed explanation on the use of single or of multiple content keys to protect one or several tracks in a streamset, please refer to the [Encryption Contract](encryption-contract-v2.md) documentation section.\$1* 

# SPEKE API v2 - Encryption contract
<a name="encryption-contract-v2"></a>

The encryption contract defines which content keys are protecting which tracks inside a given streamset, based on the tracks characteristics.

Using multiple content keys for different tracks in a streamset, despite being a recommended industry best practice, is not mandatory, but recommended - at least two different content keys, one for audio tracks and one for video tracks. Using a single content key to encrypt multiple tracks is possible but needs to be explicitly signaled in the CPIX document sent by the encryptor to to key provider. Generally speaking, the encryptor always describes precisely how many content keys are required and how they are leveraged to encrypt the various media tracks.

**Principles**  
The encryption contract is located in the `<cpix:ContentKeyUsageRuleList>` section of the CPIX document. In this section, each content key defined in the `<cpix:ContentKeyList>` section corresponds to a specific `<cpix:ContentKeyUsageRule>` element, which shall include:
+ a `ContentKeyUsageRule@intendedTrackType` attribute that can reference one or more sub-components, separated by the '\$1' sign if multiple sub-components are used. The value of `ContentKeyUsageRule@intendedTrackType` shall be unique in an encryption contract, and can not be used in multiple `ContentKeyUsageRule` elements.
+ one or more `<cpix:AudioFilter>` or `<cpix:VideoFilter>` child element, depending on the value of `ContentKeyUsageRule@intendedTrackType` attribute.

The rules governing this relationship are the following:
+ When all the audio and video tracks of the streamset need to be protected with a unique content key, the string `'ALL'` must be used as the `ContentKeyUsageRule@intendedTrackType` attribute value. Example 1 shows such a use case. In this situation, both a `<cpix:AudioFilter />` and a `<cpix:VideoFilter />` child elements without any attribute shall be included. Any other combination of `<cpix:AudioFilter>` and/or `<cpix:VideoFilter>` elements is invalid in this particular context.
+ For all other use cases, the value of the `ContentKeyUsageRule@intendedTrackType` attribute can be freely defined, and the number of `<cpix:AudioFilter />` and a `<cpix:VideoFilter />` child elements must correspond to the number of sub-components aggregated through the '\$1' sign. Examples 2/3/4/5/6/7/9/10 illustrate this requirement, when a single sub-component is present in the `ContentKeyUsageRule@intendedTrackType` attribute value. Example 8 illustrate it when multiple sub-components are used: `ContentKeyUsageRule@intendedTrackType="SD+HD"` is described by two distinct `<cpix:VideoFilter>` child elements with different attributes values, and `ContentKeyUsageRule@intendedTrackType="HDR+HFR+UHD"` is described by three distinct `<cpix:VideoFilter>` child elements with different attributes values.

**Filters**  
CPIX defines multiple filtering elements and attributes, but SPEKE supports only a subset of it. The following table summarizes these differences:


| CPIX filter type | Overall SPEKE support | Filter attributes supported by SPEKE | Filter attributes not supported by SPEKE | 
| --- | --- | --- | --- | 
|  <cpix:VideoFilter>  |  Yes  |  minPixels, maxPixels, hdr, minFps, maxFps (optional attributes)  |  wcg  | 
|  <cpix:AudioFilter>  |  Yes  |  minChannels, maxChannels (optional attributes)  |  | 
|  <cpix:KeyPeriodFilter>  |  Yes  |  periodId (mandatory attribute)  |  | 
|  <cpix:BitrateFilter>  |  No  |  N/A  |  N/A  | 
|  <cpix:LabelFilter>  |  No  |  N/A  |  N/A  | 

As per the CPIX specification for VideoFilter, [minPixels, maxPixels] is an all inclusive range in both dimensions, while (minFps, maxFps] is inclusive only for the maxFps dimension. For AudioFilter, [minChannels, maxChannels] is an inclusive range in both dimensions.

**Problematic situations**  
There are situations where the information provided in the encryption contract might be partial, ambiguous or erroneous. In these cases, it is important that the encryptor and the key provider behave appropriately and guarantee a proper protection of the contents. The following table presents the recommended behavior in these situations:


| In this situation | The encryptor should/shall …​ | The key provider should/shall …​ | 
| --- | --- | --- | 
|  No rule applies to one or more tracks in the streamset (see example 3 below)  |  The encryptor should look at its configuration (external to the CPIX payload) and verify that the concerned tracks don’t require encryption. If it’s not the expectation, the encryptor should throw an error and stop processing.  |   *Not relevant: the key provider doesn’t have knowledge of the streamset structure.*   | 
|  Multiple rules overlap and suggest multiple content keys to encrypt a specific track  |  The encryptor should apply the last ContentKeyUsageRule successfully evaluated in the order of the document.  |   *Not relevant: the key provider doesn’t have knowledge of the streamset structure.*   | 
|  The encryption contract changes in a single SPEKE request/response cycle  |  The encryptor shall raise an exception and stop processing, as the key provider is not responsible for defining the encryption contract.  |  To prevent this situation to happen in the first place, the key provider must not modify an encryption contract received in the CPIX payload of the SPEKE request.  | 
|  Malformed encryption contract: intendedTrackType/Filters cardinality constraint exception, unsupported filters or attributes  |  The encryptor shall raise an exception, stop processing and not send the SPEKE request to the key provider, as it would most likely result in erroneous content protection or leave some tracks unprotected.  |  The key provider shall raise an exception and return a 'Malformed encryption contract' error.  | 
|  Well formed encryption contract, but in breach of the DRM security levels constraints: as an example, a single content key being requested to protect both audio tracks and UHD video tracks  |  If the encryptor has got knowledge of the DRM security levels constraints, it should raise an exception, stop processing and not send the SPEKE request to the key provider, as it would most likely result in erroneous content protection.  |  The key provider shall raise an exception and return a 'Requested CPIX encryption contract not supported' error.  | 
|  Missing encryption contract  |  The encryptor shall not send CPIX documents which don’t contain any VideoFilter or AudioFilter element.  |  The key provider shall raise an exception and return a 'Missing CPIX encryption contract' error.  | 

**Examples of Encryption Contracts**  
 *Example 1: one content key for all audio and video tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="ALL">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
		<cpix:VideoFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 2: one content key for all video tracks, one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
    <cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
        <cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
        <cpix:VideoFilter />
    </cpix:ContentKeyUsageRule>
    <cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
        <cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
        <cpix:AudioFilter />
    </cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 3: one content key for all video tracks, unencrypted audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 4: multiple content keys for different video tracks (SD/HD), one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for SD video tracks (up to 1024x576) -->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="SD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter maxPixels="589824" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for HD video tracks (more than 1024x576) -->
	<cpix:ContentKeyUsageRule kid="37e3de05-9a3b-4c69-8970-63c17a95e0b7" intendedTrackType="HD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="589825" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for all audio tracks -->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 5: multiple content keys for different video tracks (SD/HD/UHD), one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for SD video tracks (up to 1024x576) -->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="SD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter maxPixels="589824" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for HD video tracks (more than 1024x576, up to 1920x1080) -->
	<cpix:ContentKeyUsageRule kid="37e3de05-9a3b-4c69-8970-63c17a95e0b7" intendedTrackType="HD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="589825" maxPixels="2073600" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for UHD video tracks (more than 1920x1080) -->
	<cpix:ContentKeyUsageRule kid="75c6fa78-8b5d-6d75-9653-26f41b78d1a3" intendedTrackType="UHD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="2073601" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for all audio tracks -->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 6: multiple content keys for different video tracks (SD/HD/UHD1/UHD2), one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for SD video tracks (up to 1024x576) -->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="SD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter maxPixels="589824" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for HD video tracks (more than 1024x576, up to 1920x1080) -->
	<cpix:ContentKeyUsageRule kid="37e3de05-9a3b-4c69-8970-63c17a95e0b7" intendedTrackType="HD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="589825" maxPixels="2073600" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for UHD1 video tracks (more than 1920x1080, up to 4096x2160) -->
	<cpix:ContentKeyUsageRule kid="75c6fa78-8b5d-6d75-9653-26f41b78d1a3" intendedTrackType="UHD1">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="2073601" maxPixels="8847360" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for UHD2 video tracks (more than 4096x2160) -->
	<cpix:ContentKeyUsageRule kid="63d2ec36-6b7c-9f34-4546-97d01f36f7c5" intendedTrackType="UHD2">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="8847361" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for all audio tracks -->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 7: multiple content keys for different video tracks (SD/HD1/HD2/UHD1/UHD2), one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for SD video tracks (up to 1024x576) -->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="SD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter maxPixels="589824" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for HD1 video tracks (more than 1024x576, up to 1280x720) -->
	<cpix:ContentKeyUsageRule kid="37e3de05-9a3b-4c69-8970-63c17a95e0b7" intendedTrackType="HD1">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="589825" maxPixels="921600" />
	</cpix:ContentKeyUsageRule>
        <!-- Rule for HD2 video tracks (more than 1280x720, up to 1920x1080) -->
          <cpix:ContentKeyUsageRule kid="cda406d8-9d87-4f76-92da-31110e756176" intendedTrackType="HD2">
            <cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
            <cpix:VideoFilter minPixels="921601" maxPixels="2073600" />
          </cpix:ContentKeyUsageRule>
	<!-- Rule for UHD1 video tracks (more than 1920x1080, up to 4096x2160) -->
	<cpix:ContentKeyUsageRule kid="75c6fa78-8b5d-6d75-9653-26f41b78d1a3" intendedTrackType="UHD1">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="2073601" maxPixels="8847360" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for UHD2 video tracks (more than 4096x2160) -->
	<cpix:ContentKeyUsageRule kid="63d2ec36-6b7c-9f34-4546-97d01f36f7c5" intendedTrackType="UHD2">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter minPixels="8847361" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for all audio tracks -->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 8: multiple content keys for different video tracks (based on multiple attributes types), one content key for all audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for SD and HD video tracks-->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="SD+HD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter maxPixels="442368" maxFps="30" hdr="false"/>
		<cpix:VideoFilter minPixels="442369" maxPixels="2073600" maxFps="30" hdr="false"/>
	</cpix:ContentKeyUsageRule>
	<!-- Rule for HDR, HFR and UHD video tracks-->
	<cpix:ContentKeyUsageRule kid="37e3de05-9a3b-4c69-8970-63c17a95e0b7" intendedTrackType="HDR+HFR+UHD">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter hdr="true" />
		<cpix:VideoFilter minFps="30" />
		<cpix:VideoFilter minPixels="20736001" />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for all audio tracks-->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter />
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 9: one content keys for all video tracks, multiple content keys for stereo and multichannel audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for video tracks-->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for stereo audio tracks-->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="STEREO_AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter maxChannels="2"/>
	</cpix:ContentKeyUsageRule>
	<!-- Rule for multichannel audio tracks-->
	<cpix:ContentKeyUsageRule kid="7ae8e96f-309e-42c3-a510-24023d923373" intendedTrackType="MULTICHANNEL_AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<AudioFilter minChannels="3"/>
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

 *Example 10: one content keys for all video tracks, multiple content keys for stereo and two types of multichannel audio tracks* 

```
<cpix:ContentKeyUsageRuleList>
	<!-- Rule for video tracks-->
	<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:VideoFilter />
	</cpix:ContentKeyUsageRule>
	<!-- Rule for stereo audio tracks-->
	<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="STEREO_AUDIO">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter maxChannels="2"/>
	</cpix:ContentKeyUsageRule>
	<!-- Rule for multichannel audio tracks (3 to 6 channels)-->
	<cpix:ContentKeyUsageRule kid="7ae8e96f-309e-42c3-a510-24023d923373" intendedTrackType="MULTICHANNEL_AUDIO_3_6">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter minChannels="3" maxChannels="6"/>
	</cpix:ContentKeyUsageRule>
  <!-- Rule for multichannel audio tracks (7 channels and more)-->
	<cpix:ContentKeyUsageRule kid="81eb3761-55ff-4d22-a31d-94f01bbfd8ba" intendedTrackType="MULTICHANNEL_AUDIO_7">
		<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
		<cpix:AudioFilter minChannels="7"/>
	</cpix:ContentKeyUsageRule>
</cpix:ContentKeyUsageRuleList>
```

# SPEKE API v2 - Live workflow method call examples
<a name="live-workflow-methods-v2"></a>

 *Request Syntax Example* 

The following URL is an example and does not indicate a fixed format:

```
POST https://speke-compatible-server/speke/v2.0/copyProtection
```

 *Request Body* 

A CPIX document.

 *Request Headers* 


| Name | Type | Occurs | Description | 
| --- | --- | --- | --- | 
|   `AWS Authorization`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `X-Amz-Security-Token`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `X-Amz-Date`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `Content-Type`   |  String  |  1..1  |  application/xml  | 
|   `X-Speke-Version`   |  String  |  1..1  |  SPEKE API version used with the request, formulated as MajorVersion.MinorVersion, like '2.0' for SPEKE v2.0  | 

 *Response Headers* 


| Name | Type | Occurs | Description | 
| --- | --- | --- | --- | 
|   `X-Speke-User-Agent`   |  String  |  1..1  |  String that identifies the key provider  | 
|   `Content-Type`   |  String  |  1..1  |  application/xml  | 
|   `X-Speke-Version`   |  String  |  1..1  |  SPEKE API version used with the request, formulated as MajorVersion.MinorVersion, like '2.0' for SPEKE v2.0  | 

 *Request Response* 


| HTTP CODE | Payload Name | Occurs | Description | 
| --- | --- | --- | --- | 
|   `200 (Success)`   |  CPIX  |  1..1  |  DASH-CPIX payload response  | 
|   `4XX (Client error)`   |  Client error message  |  1..1  |  Description of the client error  | 
|   `5XX (Server error)`   |  Server error message  |  1..1  |  Description of the server error  | 

**Note**  
The examples in this section do not include content key encryption. For information on how to add content key encryption, see [Content key encryption](content-key-encryption-v2.md).

 *Live Example Request Payload with Keys in the Clear* 

The following example shows a typical live request payload from the encryptor to the DRM key provider, with one content key for all video tracks and one content key for all audio tracks:

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs"></cpix:ContentKey>
		<cpix:ContentKey explicitIV="L6jzdXrXAFbCJGBuMrrKrG==" kid="53abdba2-f210-43cb-bc90-f18f9a890a02" commonEncryptionScheme="cbcs"></cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- FairPlay -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<!-- Widevine -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
		</cpix:DRMSystem>
		<!-- Playready -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData></cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData></cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyPeriodList>
		<cpix:ContentKeyPeriod id="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f" index="1" />
	</cpix:ContentKeyPeriodList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
		<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:AudioFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```

 *Live Example Response Payload with Keys in the Clear* 

The following example shows a typical response payload from the DRM key provider (returned values have been shortened with […​] for readability):

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>5dGAgwGuUYu4dHeHtNlxJw==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
		<cpix:ContentKey explicitIV="L6jzdXrXAFbCJGBuMrrKrG==" kid="53abdba2-f210-43cb-bc90-f18f9a890a02" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>h3toSFIlyAYpfXVQ795m6x==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- FairPlay -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media">aHR0cHM6L[...]WZm</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">Y29tLmFwc[...]XJ5</cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media">trBAnbMcj[...]u44</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">mn626PjyR[...]2fi</cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<!-- Widevine -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media">Ifa2V5LWl[...]nNB</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">oIARIQeSI[...]Nd2l</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>RoNd2lkZXZ[...]Nib</cpix:ContentProtectionData>
			<cpix:PSSH>AAAAanBzc[...]A==</cpix:PSSH>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media">lTznjvtzL[...]GfJ</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">XgzdzQH7p[...]zeX</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>TdgRnuJsZ[...]wDw</cpix:ContentProtectionData>
			<cpix:PSSH>mYZbjpWdS[...]D==</cpix:PSSH>
		</cpix:DRMSystem>
		<!-- Playready -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media">HicXmbZ2m[...]4==</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">GVzdCIfa2[...]Eta</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>t7WwH24FI[...]YCC</cpix:ContentProtectionData>
			<cpix:PSSH>FFFFanBzc[...]A==</cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData>s5RrJ12HL[...]UBB</cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media">BptGzwis2[...]Iej</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">3c9SXdVa0[...]MBH</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>HotJCMQyc[...]GpU</cpix:ContentProtectionData>
			<cpix:PSSH>S6UD43ybN[...]f==</cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData>VBFUv2or0[...]JeP</cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyPeriodList>
		<cpix:ContentKeyPeriod id="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f" index="1" />
	</cpix:ContentKeyPeriodList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
		<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:AudioFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```

# SPEKE API v2 - VOD workflow method call examples
<a name="vod-workflow-method-v2"></a>

 *Request Syntax Example* 

The following URL is an example and does not indicate a fixed format.

```
POST https://speke-compatible-server/speke/v2.0/copyProtection
```

 *Request Body* 

A CPIX document.

 *Request Headers* 


| Name | Type | Occurs | Description | 
| --- | --- | --- | --- | 
|   `AWS Authorization`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `X-Amz-Security-Token`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `X-Amz-Date`   |  String  |  1..1  |  See [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)   | 
|   `Content-Type`   |  String  |  1..1  |  application/xml  | 
|   `X-Speke-Version`   |  String  |  1..1  |  SPEKE API version used with the request, formulated as MajorVersion.MinorVersion, like '2.0' for SPEKE v2.0  | 

 *Response Headers* 


| Name | Type | Occurs | Description | 
| --- | --- | --- | --- | 
|   `X-Speke-User-Agent`   |  String  |  1..1  |  String that identifies the key provider  | 
|   `Content-Type`   |  String  |  1..1  |  application/xml  | 
|   `X-Speke-Version`   |  String  |  1..1  |  SPEKE API version used with the request, formulated as MajorVersion.MinorVersion, like '2.0' for SPEKE v2.0  | 

 *Request Response* 


| HTTP CODE | Payload Name | Occurs | Description | 
| --- | --- | --- | --- | 
|   `200 (Success)`   |  CPIX  |  1..1  |  DASH-CPIX payload response  | 
|   `4XX (Client error)`   |  Client error message  |  1..1  |  Description of the client error  | 
|   `5XX (Server error)`   |  Server error message  |  1..1  |  Description of the server error  | 

**Note**  
The examples in this section do not include content key encryption. For information on how to add content key encryption, see [Content key encryption](content-key-encryption-v2.md).

 *VOD Example Request Payload with Keys in the Clear* 

The following example shows a typical VOD request payload from the encryptor to the DRM key provider, with one content key for all video tracks and one content key for all audio tracks:

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs"></cpix:ContentKey>
		<cpix:ContentKey explicitIV="L6jzdXrXAFbCJGBuMrrKrG==" kid="53abdba2-f210-43cb-bc90-f18f9a890a02" commonEncryptionScheme="cbcs"></cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- FairPlay -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<!-- Widevine -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
		</cpix:DRMSystem>
		<!-- Playready -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData></cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData></cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
		<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
			<cpix:AudioFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```

 *VOD Example Response Payload with Keys in the Clear* 

The following example shows a typical response payload from the DRM key provider (returned values have been shortened with […​] for readability):

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>5dGAgwGuUYu4dHeHtNlxJw==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
		<cpix:ContentKey explicitIV="L6jzdXrXAFbCJGBuMrrKrG==" kid="53abdba2-f210-43cb-bc90-f18f9a890a02" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>h3toSFIlyAYpfXVQ795m6x==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- FairPlay -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media">aHR0cHM6L[...]WZm</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">Y29tLmFwc[...]XJ5</cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2">
			<cpix:HLSSignalingData playlist="media">trBAnbMcj[...]u44</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">mn626PjyR[...]2fi</cpix:HLSSignalingData>
		</cpix:DRMSystem>
		<!-- Widevine -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media">Ifa2V5LWl[...]nNB</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">oIARIQeSI[...]Nd2l</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>RoNd2lkZXZ[...]Nib</cpix:ContentProtectionData>
			<cpix:PSSH>AAAAanBzc[...]A==</cpix:PSSH>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media">lTznjvtzL[...]GfJ</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">XgzdzQH7p[...]zeX</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>TdgRnuJsZ[...]wDw</cpix:ContentProtectionData>
			<cpix:PSSH>mYZbjpWdS[...]D==</cpix:PSSH>
		</cpix:DRMSystem>
		<!-- Playready -->
		<cpix:DRMSystem kid="98ee5596-cd3e-a20d-163a-e382420c6eff" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media">HicXmbZ2m[...]4==</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">GVzdCIfa2[...]Eta</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>t7WwH24FI[...]YCC</cpix:ContentProtectionData>
			<cpix:PSSH>FFFFanBzc[...]A==</cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData>s5RrJ12HL[...]UBB</cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
		<cpix:DRMSystem kid="53abdba2-f210-43cb-bc90-f18f9a890a02" systemId="9a04f079-9840-4286-ab92-e65be0885f95">
			<cpix:HLSSignalingData playlist="media">BptGzwis2[...]Iej</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">3c9SXdVa0[...]MBH</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>HotJCMQyc[...]GpU</cpix:ContentProtectionData>
			<cpix:PSSH>S6UD43ybN[...]f==</cpix:PSSH>
			<cpix:SmoothStreamingProtectionHeaderData>VBFUv2or0[...]JeP</cpix:SmoothStreamingProtectionHeaderData>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="98ee5596-cd3e-a20d-163a-e382420c6eff" intendedTrackType="VIDEO">
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
		<cpix:ContentKeyUsageRule kid="53abdba2-f210-43cb-bc90-f18f9a890a02" intendedTrackType="AUDIO">
			<cpix:AudioFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```

# SPEKE API v2 - Content key encryption
<a name="content-key-encryption-v2"></a>

You can optionally add content key encryption to your SPEKE implementation. Content key encryption guarantees full end-to-end protection by encrypting the content keys for transit, in addition to encrypting the content itself. If you don’t implement this for your key provider, you rely on the transport layer encryption plus strong authentication for security.

To use content key encryption for encryptors running in AWS Cloud, customers import certificates into the AWS Certificate Manager and then use the resulting certificate ARNs for their encryption activities. The encryptor uses the certificate ARNs and the ACM service to provide encrypted content keys to the DRM key provider.

**Restrictions**  
SPEKE supports content key encryption as specified in the DASH-IF CPIX specification with the following restrictions:
+ SPEKE doesn’t support digital signature verification (XMLDSIG) for request or response payloads.
+ SPEKE requires 2048 RSA-based certificates.

These restrictions are also listed in [Customizations and constraints to the DASH-IF specification](speke-constraints-v2.md).

**Implement content key encryption**  
To provide content key encryption, include the following in your DRM key provider implementations:
+ Handle the element `<cpix:DeliveryDataList>` in the request and response payloads.
+ Provide encrypted values in the `<cpix:ContentKeyList>` of the response payloads.

For more information about these elements, see the [DASH-IF CPIX 2.3 specification](https://dashif.org/docs/CPIX2.3/Cpix.html).

 *Example Content Key Encryption Element ` <cpix:DeliveryDataList> ` in the Request Payload* 

```
<cpix:CPIX contentId="abc123"
    version="2.3"
    xmlns:cpix="urn:dashif:org:cpix"
    xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
    <cpix:DeliveryDataList>
        <cpix:DeliveryData id="<ORIGIN SERVER ID>">
            <cpix:DeliveryKey>
                <ds:X509Data>
                    <ds:X509Certificate><X.509 CERTIFICATE, BASE-64 ENCODED></ds:X509Certificate>
                </ds:X509Data>
            </cpix:DeliveryKey>
        </cpix:DeliveryData>
    </cpix:DeliveryDataList>
    <cpix:ContentKeyList>
     ...
    </cpix:ContentKeyList>
</cpix:CPIX>
```

 *Example Content Key Encryption Element ` <cpix:DeliveryDataList> ` in the Response Payload* 

```
<cpix:CPIX contentId="abc123"
    version="2.3"
    xmlns:cpix="urn:dashif:org:cpix"
    xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
    <cpix:DeliveryDataList>
        <cpix:DeliveryData id="<ORIGIN SERVER ID>">
            <cpix:DeliveryKey>
                <ds:X509Data>
                    <ds:X509Certificate><X.509 CERTIFICATE, BASE-64 ENCODED></ds:X509Certificate>
                </ds:X509Data>
            </cpix:DeliveryKey>
            <cpix:DocumentKey Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc">
                <cpix:Data>
                    <pskc:Secret>
                        <pskc:EncryptedValue>
                            <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
                            <enc:CipherData>
                                <enc:CipherValue><RSA CIPHER VALUE></enc:CipherValue>
                            </enc:CipherData>
                        </pskc:EncryptedValue>
                        <pskc:ValueMAC>qnei/5TsfUwDu+8bhsZrLjDRDngvmnUZD2eva7SfXWw=</pskc:ValueMAC>
                    </pskc:Secret>
                </cpix:Data>
            </cpix:DocumentKey>
            <cpix:MACMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512">
                <cpix:Key>
                    <pskc:EncryptedValue>
                        <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
                        <enc:CipherData>
                            <enc:CipherValue><RSA CIPHER VALUE></enc:CipherValue>
                        </enc:CipherData>
                    </pskc:EncryptedValue>
                    <pskc:ValueMAC>DGqdpHUfFKxdsO9+EWrPjtdTCVfjPLwwtzEcFC/j0xY=</pskc:ValueMAC>
                </cpix:Key>
            </cpix:MACMethod>
        </cpix:DeliveryData>
    </cpix:DeliveryDataList>
    <cpix:ContentKeyList>
     ...
    </cpix:ContentKeyList>
</cpix:CPIX>
```

 *Example Content Key Encryption Element ` <cpix:ContentKeyList> ` in the Response Payload* 

The following example shows encrypted content key handling in the `<cpix:ContentKeyList>` element of the response payload. This uses the `<pskc:EncryptedValue>` element:

```
<cpix:ContentKeyList>
     <cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs">
         <cpix:Data>
             <pskc:Secret>
                 <pskc:EncryptedValue>
                     <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
                     <enc:CipherData>
                         <enc:CipherValue>NJYebfvJ2TdMm3k6v+rLNVYb0NoTJoTLBBdbpe8nmilEfp82SKa7MkqTn2lmQBPB</enc:CipherValue>
                     </enc:CipherData>
                 </pskc:EncryptedValue>
                 <pskc:ValueMAC>t9lW4WCebfS1GP+dh0IicMs+2+jnrAmfDa4WU6VGHc4=</pskc:ValueMAC>
             </pskc:Secret>
         </cpix:Data>
     </cpix:ContentKey>
 </cpix:ContentKeyList>
```

By comparison, the following example shows a similar response payload with the content key delivered unencrypted, as a clear key. This uses the `<pskc:PlainValue>` element:

```
<cpix:ContentKeyList>
    <cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="98ee5596-cd3e-a20d-163a-e382420c6eff" commonEncryptionScheme="cbcs">
        <cpix:Data>
            <pskc:Secret>
                <pskc:PlainValue>5dGAgwGuUYu4dHeHtNlxJw==</pskc:PlainValue>
            </pskc:Secret>
        </cpix:Data>
    </cpix:ContentKey>
</cpix:ContentKeyList>
```

# SPEKE API v2 - Overriding the key identifier
<a name="kid-override-v2"></a>

The encryptor creates a new key identifier (KID) each time that it rotates keys. It passes the KID to the DRM key provider in its requests. Almost always, the key provider responds using the same KID, but it can provide a different value for the KID in the response.

The following is an example request with the KID `11111111-1111-1111-1111-111111111111`:

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="11111111-1111-1111-1111-111111111111" commonEncryptionScheme="cbcs"></cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- Widevine -->
		<cpix:DRMSystem kid="11111111-1111-1111-1111-111111111111" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media"></cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master"></cpix:HLSSignalingData>
			<cpix:ContentProtectionData></cpix:ContentProtectionData>
			<cpix:PSSH></cpix:PSSH>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyPeriodList>
		<cpix:ContentKeyPeriod id="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f" index="1" />
	</cpix:ContentKeyPeriodList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="11111111-1111-1111-1111-111111111111" intendedTrackType="VIDEO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```

The following response overrides the KID to `22222222-2222-2222-2222-222222222222`:

```
<cpix:CPIX contentId="abc123" version="2.3" xmlns:cpix="urn:dashif:org:cpix" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<cpix:ContentKeyList>
		<cpix:ContentKey explicitIV="OFj2IjCsPJFfMAxmQxLGPw==" kid="22222222-2222-2222-2222-222222222222" commonEncryptionScheme="cbcs">
			<cpix:Data>
				<pskc:Secret>
					<pskc:PlainValue>5dGAgwGuUYu4dHeHtNlxJw==</pskc:PlainValue>
				</pskc:Secret>
			</cpix:Data>
		</cpix:ContentKey>
	</cpix:ContentKeyList>
	<cpix:DRMSystemList>
		<!-- Widevine -->
		<cpix:DRMSystem kid="22222222-2222-2222-2222-222222222222" systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
			<cpix:HLSSignalingData playlist="media">Ifa2V5LWl[...]nNB</cpix:HLSSignalingData>
			<cpix:HLSSignalingData playlist="master">oIARIQeSI[...]Nd2l</cpix:HLSSignalingData>
			<cpix:ContentProtectionData>RoNd2lkZXZ[...]Nib</cpix:ContentProtectionData>
			<cpix:PSSH>AAAAanBzc[...]A==</cpix:PSSH>
		</cpix:DRMSystem>
	</cpix:DRMSystemList>
	<cpix:ContentKeyPeriodList>
		<cpix:ContentKeyPeriod id="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f" index="1" />
	</cpix:ContentKeyPeriodList>
	<cpix:ContentKeyUsageRuleList>
		<cpix:ContentKeyUsageRule kid="22222222-2222-2222-2222-222222222222" intendedTrackType="VIDEO">
			<cpix:KeyPeriodFilter periodId="keyPeriod_0909829f-40ff-4625-90fa-75da3e53278f"/>
			<cpix:VideoFilter />
		</cpix:ContentKeyUsageRule>
	</cpix:ContentKeyUsageRuleList>
</cpix:CPIX>
```