本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
SPEKEAPIv2
这是 Secure Packager 和 Encoder 密钥交换 (SPEKE) v2 的。REST API使用本规范为使用加密的客户提供DRM版权保护。为了SPEKE符合要求，您的DRM密钥提供程序必须公开本规范中RESTAPI描述的。加密器会API调用您的密钥提供商。
注意
本规范中的代码示例仅用于说明目的。你无法运行这些示例，因为它们不是完整SPEKE实现的一部分。
SPEKE使用DASH行业论坛内容保护信息交换格式 (DASH-IF-CPIX) 数据结构定义进行密钥交换，但有一些限制。DASH-IF-CPIX 定义了一个架构，以提供从DRM平台到加密器的可扩展的多重DRM交换。这使得在内容压缩和打包时允许对所有自适应比特率打包格式进行内容加密。自适应比特率打包格式包括HLSDASH、和。MSS
从其版本 2.0 开始SPEKE，与特定CPIX版本保持一致：
SPEKE一方面，这是通过使用X-Speke-VersionHTTP标题来强制执行的，CPIX另一方面是通过使用CPIX@version属性来强制执行的。请求中缺少这些元素是 SPEKE v1 传统工作流程的典型特征。在 SPEKE v2 工作流程中，只有当密钥提供程序同时支持两个版本参数时，它才需要处理CPIX文档。
有关交换格式的详细信息，请参阅DASH行业论坛 CPIX2.3 规范
总体而言，与 SPEKE v1.0 相比，v2.0 带来了以下变化：SPEKE
-
不推荐使用SPEKEXML命名空间中的所有标签，取而代之的是命名空间中的CPIXXML等效标签
-
SPEKE:ProtectionHeader已弃用并替换为CPIX:DRMSystem.SmoothStreamingProtectionHeaderData -
CPIX:URIExtXKey、SPEKE:KeyFormat和SPEKE:KeyFormatVersions已弃用并替换为CPIX:DRMSystem.HLSSignalingData -
CPIX@id替换为CPIX@contentId -
新的必填CPIX属性：
CPIX@version，ContentKey@commonEncryptionScheme -
新的可选CPIX元素：
DRMSystem.ContentProtectionData -
支持多个内容密钥
-
和之间的跨版本控制机制 SPEKE CPIX
-
HTTP标题演变：新
X-Speke-Version标题，标Speke-User-Agent题重命名为X-Speke-User-Agent -
心跳API已被弃用
由SPEKE于 v1.0 规范保持不变，因此无需更改现有实现即可继续支持 SPEKE v1.0 工作流程。
主题
