

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# SPEKE API v2: personalizaciones y restricciones a la especificación de DASH-IF
<a name="speke-constraints-v2"></a>

La [especificación CPIX 2.3](https://dashif.org/docs/CPIX2.3/Cpix.html) DASH Industry Forum admite una serie de casos de uso y topologías. La especificación SPEKE API v2.0 define tanto un perfil CPIX como una API para CPIX. Para alcanzar estos dos objetivos, se ajusta a la especificación CPIX con las siguientes personalizaciones y restricciones:

**Perfil CPIX**
+ SPEKE sigue el flujo de trabajo Encriptador-Consumidor.
+ En las claves de contenido cifradas, SPEKE aplica las siguientes restricciones:
  + SPEKE no admite la verificación de firma digital (XMLDSIG) para cargas de solicitud o respuesta.
  + SPEKE requiere 2048 certificados basados en RSA.
+ SPEKE aprovecha solo un subconjunto de funcionalidades del CPIX:
  + SPEKE omite la funcionalidad `UpdateHistoryItemList`. Si la lista está presente en la respuesta, SPEKE la omite.
  + SPEKE omite la funcionalidad clave. root/leaf Si el atributo `ContentKey@dependsOnKey` está presente en la respuesta, SPEKE la omite.
  + SPEKE omite el elemento `BitrateFilter` y el atributo `VideoFilter@wcg`. Si estos elementos o atributos están presentes en la carga del CPIX, SPEKE los omite.
+ En los documentos del CPIX intercambiados con SPEKE v2, solo se pueden utilizar los elementos o atributos a los que se hace referencia como “compatibles” en la [página de componentes de carga estándar](standard-payload-components-v2.md) o en la [página del contrato de cifrado](encryption-contract-v2.md).
+ Cuando el encriptador los incluya en una solicitud de CPIX, todos los elementos y atributos deberán incluir un valor válido en la respuesta del CPIX del proveedor de claves. De lo contrario, el encriptador se detendrá y generará un error.
+ SPEKE admite la rotación de claves con elementos `KeyPeriodFilter`. SPEKE utiliza únicamente el `ContentKeyPeriod@index` para realizar un seguimiento del período clave.
+ Para la señalización HLS, se deben utilizar varios elementos `DRMSystem.HLSSignalingData`: uno con el valor de atributo `DRMSystem.HLSSignalingData@playlist` de “multimedia” y otro con un valor de atributo `DRMSystem.HLSSignalingData@playlist` de “maestro”.
+ Al solicitar claves, el encriptador puede utilizar el atributo `@explicitIV` opcional en el elemento `ContentKey`. El proveedor de claves puede responder con un IV mediante `@explicitIV`, aunque el atributo no esté incluido en la solicitud.
+ El encriptador crea el identificador de la clave (`KID`), que es el mismo para cualquier ID de contenido y periodo de clave especificados. El proveedor de claves incluye el `KID` en la respuesta al documento de solicitud.
+ El encriptador incluirá un valor para el atributo `CPIX@contentId`. Al recibir un valor vacío para este atributo, el proveedor de claves devolverá un error con la descripción “Missing CPIX@contentId” (Falta CPIX@contentId). El proveedor de claves no puede anular un valor `CPIX@contentId`.

   El proveedor de claves ignorará el valor `CPIX@id` si no es nulo.
+ El encriptador incluirá un valor para el atributo `CPIX@version`. Al recibir un valor vacío para este atributo, el proveedor de claves devolverá un error con la descripción “Missing CPIX@version” (Falta CPIX@version). Al recibir una solicitud con una versión no compatible, la descripción del error devuelta por el proveedor de claves será “Unsupported CPIX@version” (CPIX@version no compatible).

   El proveedor de claves no puede anular un valor `CPIX@version`.
+ El encriptador incluirá un valor para el atributo `ContentKey@commonEncryptionScheme` de cada clave solicitada. Al recibir un valor vacío para este atributo, el proveedor de claves devolverá un error con la descripción «Falta ContentKey @ commonEncryptionScheme para KID». `id`

  Un documento CPIX único no puede mezclar varios valores para distintos atributos `ContentKey@commonEncryptionScheme`. Al recibir dicha combinación, el proveedor de claves devolverá un error con la descripción «Combinación ContentKey @ commonEncryptionScheme no conforme».

  No todos los valores `ContentKey@commonEncryptionScheme` son compatibles con todas las tecnologías DRM. Al recibir dicha combinación, el proveedor de claves devolverá un error con la descripción «ContentKey@ commonEncryptionScheme no compatible con DRMSystem `id`».

   El proveedor de claves no puede anular un valor `ContentKey@commonEncryptionScheme`.
+ Al recibir valores diferentes para elemento `<pssh>` innerXML `DRMSystem@PSSH` y `DRMSystem.ContentProtectionData` en el cuerpo de la respuesta del CPIX, el encriptador se detendrá y generará un error.

**API para CPIX**
+ El proveedor de claves debe incluir un valor para el encabezado de respuesta HTTP `X-Speke-User-Agent`.
+ Un encriptador compatible con SPEKE actúa como cliente y envía operaciones de POST al punto de conexión del proveedor de claves.
+ El cifrador incluirá un valor para el encabezado de la solicitud `X-Speke-Version` HTTP, y la versión SPEKE utilizada en la solicitud se formulará como. MajorVersion MinorVersion, como «2.0» para SPEKE v2.0. Si el proveedor de claves no admite la versión SPEKE utilizada por el encriptador para la solicitud actual, devolverá un error con la descripción “Unsupported SPEKE version” (versión no compatible con SPEKE) y en la medida de lo posible no procesará el documento CPIX.

  El proveedor de claves no puede modificar el valor del encabezado `X-Speke-Version` definido por el encriptador en respuesta a la solicitud.
+ Al recibir errores en el cuerpo de la respuesta, el encriptador emitirá un error y no volverá a intentar la solicitud con un control de versión SPEKE v1.0.

  Si el proveedor de claves no arroja error, pero no devuelve un documento CPIX que incluya la información obligatoria, el encriptador debería detenerse y generar un error.

La siguiente tabla resume los mensajes estándar que debe devolver el proveedor de claves en el cuerpo del mensaje. En caso de error, el código de respuesta HTTP debe ser 4XX o 5XX, nunca 200. El código de error 422 se puede utilizar para todos los errores relacionados con SPEKE/CPIX.


| Caso de error | Mensaje de error | 
| --- | --- | 
|  CPIX @contentId no está definido  |  Falta CPIX @contentId  | 
|  CPIX @version no está definido  |  Falta CPIX @version  | 
|  No se admite CPIX @version  |  CPIX@version no es compatible  | 
|  ContentKey@ no commonEncryptionScheme está definido  |  Falta ContentKey @ commonEncryptionScheme para KID `id` (donde `id` es igual al valor ContentKey @kid)  | 
|  Se utilizan varios commonEncryptionScheme valores ContentKey @ en un único documento CPIX  |  Combinación @ no compatible ContentKey commonEncryptionScheme   | 
|  ContentKey@ no commonEncryptionScheme es compatible con la tecnología DRM  |  ContentKey@ commonEncryptionScheme no es compatible con DRMSystem `id` (donde `id` es igual al valor DRMSystem @systemId)  | 
|  X-Speke-Version el valor del encabezado no es una versión de SPEKE compatible  |  La versión de SPEKE no es compatible  | 
|  El contrato de cifrado es incorrecto  |  Contrato de cifrado con formato incorrecto  | 
|  El contrato de cifrado contradice las restricciones de los niveles de seguridad del DRM  |  No se admite el contrato de cifrado CPIX solicitado  | 
|  El contrato de cifrado no incluye ningún elemento VideoFilter o elemento AudioFilter   |  Falta el contrato de cifrado CPIX  | 