Speke API v2 - Personnalisations et contraintes pour la spécification DASH-IF - Spécification d'API Secure Packager and Encoder Key Exchange

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Speke API v2 - Personnalisations et contraintes pour la spécification DASH-IF

Le Forum de l'industrie DASHSpécification CPIX 2.3prend en charge un certain nombre de cas d'utilisation et de topologies. La spécification SPEKE API v2.0 définit à la fois un profil CPIX et une API pour CPIX. Pour atteindre ces deux objectifs, il est conforme à la spécification CPIX avec les personnalisations et contraintes suivantes :

Profil CPIX

  • SPEKE suit le flux de travail Encryptor Consumer.

  • Pour les clés de contenu chiffrées, SPEKE applique les restrictions suivantes :

    • SPEKE ne prend pas en charge la vérification des signatures numériques (XMLDSIG) pour les charges utiles de demandes ou de réponses.

    • SPEKE nécessite 2048 certificats RSA.

  • SPEKE exploite uniquement un sous-ensemble de fonctionnalités CPIX :

    • SPEKE omet laUpdateHistoryItemListfonctionnalité. Si la liste est présente dans la réponse, SPEKE l'ignore.

    • SPEKE omet la fonctionnalité de touche racine/feuille. Si l'icôneContentKey@dependsOnKeyest présent dans la réponse, SPEKE l'ignore.

    • SPEKE omet laBitrateFilterÉlément etVideoFilter@wcgAttribut. Si ces éléments ou attributs sont présents dans la charge utile CPIX, SPEKE l'ignore.

  • Seuls les éléments ou attributs référencés comme étant « pris en charge » sur lePage Composants de charge utile standardou lePage du contrat de chiffrementpeut être utilisé dans les documents CPIX échangés avec SPEKE v2.

  • Lorsqu'ils sont inclus dans une demande CPIX par le chiffreur, tous les éléments et attributs doivent porter une valeur valide dans la réponse CPIX du fournisseur de clés. Si ce n'est pas le cas, le chiffreur doit s'arrêter et déclencher une erreur.

  • SPEKE prend en charge la rotation des clés avecKeyPeriodFilteréléments. SPEKE utilise uniquement leContentKeyPeriod@indexpour suivre la durée d'utilisation des clés.

  • Pour la signalisation HLS, plusieursDRMSystem.HLSSignalingDatales éléments doivent être utilisés : un avec unDRMSystem.HLSSignalingData@playlistvaleur attributaire de « media », et un autre avec unDRMSystem.HLSSignalingData@playlistvaleur attributaire de « maître ».

  • Lors de la demande de clés, le chiffreur peut utiliser l'attribut facultatif @explicitIV sur l'élément ContentKey. Le fournisseur de clés peut répondre avec un vecteur d'initialisation à l'aide de @explicitIV, même si l'attribut n'est pas inclus dans la requête.

  • Le chiffreur crée l'identifiant de clé (KID), qui reste le même quels que soient l'ID de contenu et la durée d'utilisation des clés. Le fournisseur de clés inclut KID dans sa réponse au document de demande.

  • Le chiffreur doit inclure une valeur pour leCPIX@contentIdAttribut. Lorsque vous recevez une valeur vide pour cet attribut, le fournisseur de clés doit renvoyer une erreur avec la description « CPIX @contentId manquant ».CPIX@contentIdLa valeur ne peut pas être remplacée par le fournisseur de clés.

    CPIX@idvaleur, si elle n'est pas nulle, doit être ignorée par le fournisseur de clés.

  • Le chiffreur doit inclure une valeur pour leCPIX@versionAttribut. Lorsque vous recevez une valeur vide pour cet attribut, le fournisseur de clés doit renvoyer une erreur avec la description « CPIX @version manquant ». Lorsque vous recevez une demande avec une version non prise en charge, la description de l'erreur renvoyée par le fournisseur de clés doit être « CPIX @version non pris en charge ».

    CPIX@versionLa valeur ne peut pas être remplacée par le fournisseur de clés.

  • Le chiffreur doit inclure une valeur pour leContentKey@commonEncryptionSchemepour chaque clé demandée. Lorsque vous recevez une valeur vide pour cet attribut, le fournisseur de clés doit renvoyer une erreur avec la description 'Missing ContentKey @commonEncryptionScheme for KIDid ».

    Un document CPIX unique ne peut pas mélanger plusieurs valeurs pour différentes valeursContentKey@commonEncryptionSchemeAttributs. Lors de la réception d'une telle combinaison, le fournisseur de clés doit renvoyer une erreur avec la description « Combinaison ContentKey @commonEncryptionScheme non conforme ».

    Pas tousContentKey@commonEncryptionSchemeles valeurs sont compatibles avec toutes les technologies DRM. Lors de la réception d'une telle combinaison, le fournisseur de clés doit renvoyer une erreur avec la description « ContentKey @commonEncryptionScheme non compatible avec DRMSystem »id ».

    ContentKey@commonEncryptionSchemeLa valeur ne peut pas être remplacée par le fournisseur de clés.

  • Lorsque vous recevez des valeurs différentes pourDRMSystem@PSSHetDRMSystem.ContentProtectionDataXML interne<pssh>dans le corps de réponse CPIX, le chiffreur doit arrêter et déclencher une erreur.

API pour CPIX

  • Le fournisseur de clés doit inclure une valeur pour leX-Speke-User-AgentEn-tête de réponse HTTP.

  • Un chiffreur conforme à Speke agit en tant que client et envoie les opérations POST au point de terminaison du fournisseur de clés.

  • Le chiffreur doit inclure une valeur pour leX-Speke-VersionEn-tête de requête HTTP, avec la version SPEKE utilisée avec la requête, formulé comme MajorVersion.MinorVersion, comme '2.0' pour SPEKE v2.0. Si le fournisseur de clés ne prend pas en charge la version SPEKE utilisée par le chiffreur pour la demande en cours, le fournisseur de clés doit renvoyer une erreur avec la description « Version SPEKE non prise en charge » et ne doit pas essayer de traiter le document CPIX de manière optimale.

    LeX-Speke-Versionla valeur d'en-tête définie par le chiffreur ne peut pas être modifiée par le fournisseur de clés dans la réponse à la demande.

  • Lors de la réception d'erreurs dans le corps de réponse, le chiffreur doit générer une erreur et ne pas réessayer la demande avec un versionnement SPEKE v1.0.

    Si le fournisseur de clés ne renvoie pas d'erreur mais ne parvient pas à renvoyer un document CPIX contenant les informations obligatoires, le chiffreur doit arrêter et lancer une erreur.

Le tableau suivant résume les messages standard qui doivent être renvoyés par le fournisseur de clés dans le corps du message. Dans les cas d'erreur, le code de réponse HTTP doit être un 4XX ou un 5XX, jamais un 200. Le code d'erreur 422 peut être utilisé pour toutes les erreurs liées à SPEKE/CPIX.

Cas d'erreur Error message (Message d'erreur)

CPIX @contentId n'est pas défini

CPIX manquant @contentId

CPIX @version n'est pas défini

CPIX manquant @version

CPIX @version n'est pas pris en charge

CPIX @version non pris en charge

ContentKey @commonEncryptionScheme n'est pas défini

ContentKey @commonEncryptionScheme manquant pour KIDid(oùidest égal à la valeur ContentKey @kid)

Plusieurs valeurs ContentKey @commonEncryptionScheme utilisées dans un seul document CPIX

Combinaison ContentKey @commonEncryptionScheme non conforme

ContentKey @commonEncryptionScheme n'est pas compatible avec la technologie DRM

ContentKey @commonEncryptionScheme non compatible avec DRMSystemid(oùidest égal à DRMSystem @systemId (valeur)

La valeur d'en-tête X-Speke-Version n'est pas une version SPEKE prise en charge

Version SPEKE non prise en charge

Le contrat de chiffrement est mal formé

Contrat de chiffrement mal formé

Le contrat de chiffrement contredit les contraintes liées aux niveaux de sécurité DRM

Contrat de chiffrement CPIX demandé non pris en charge

Le contrat de chiffrement n'inclut pas VideoFilter ou AudioFilter élément

Contrat de chiffrement CPIX manquant