Assertions cloud-data de C2PA: cómo revisar campos y etiquetas rechazadas

Conserva la assertion y la salida completa

Guarda el activo exacto antes de abrirlo con un validador compatible con C2PA. Anota URL o ruta local, hora de obtención, identificador, nombre y versión del validador, label del active manifest, tipo de claim y salida completa. Esta hoja es una propuesta operativa del artículo, no un formato exigido por C2PA. No reexportes el archivo ni lo sustituyas por una captura antes de la primera validación.

Localiza la assertion cuyo label es c2pa.cloud-data y copia los campos tal como aparecen. Separa el label exterior del campo interno label, que identifica la external assertion referenciada. Marca como no informado lo que la herramienta no muestre; no lo deduzcas del nombre del archivo, una insignia u otro manifest.

La revisión responde una pregunta concreta: si esta cloud-data assertion cumple las reglas estructurales y de etiquetas de la sección citada. No decide si el contenido externo es exacto, seguro o auténtico.

Comprueba primero los cuatro campos obligatorios

C2PA 2.2 exige que una assertion c2pa.cloud-data contenga label, size, location y content_type. Si falta cualquiera, el claim se rechaza con assertion.cloud-data.malformed. Registra los cuatro nombres, el valor mostrado y el código exacto en la misma fila.

Distingue un campo ausente de un valor que parezca extraño. La regla citada asigna ese código cuando falta un campo obligatorio; no permite inventar valores ni declarar malformed todo valor desconocido. Si el validador solo muestra una insignia general, conserva la salida y deja sin resolver qué campo falta.

La especificación también remite la validación de location al procedimiento separado de external references. Guarda el resultado que muestre la herramienta, pero no conviertas esta revisión en un relato de recuperación de red, contenido de respuesta o comparación de hash si el validador y la fuente aplicable no aportan esos resultados.

Rechaza hard bindings detrás de cloud-data

Lee el label interno. C2PA rechaza el claim con assertion.cloud-data.hardBinding si la external assertion tiene el label c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, el obsoleto c2pa.hash.bmff.v2 o c2pa.hash.bmff.v3. Copia el label y el código literales; no lo resumas como una prohibición de todos los hashes.

La regla limita qué labels pueden referenciarse mediante c2pa.cloud-data. El rechazo no demuestra por sí solo que cambiaron los bytes, quién editó el activo ni que el hecho representado sea falso. Esas preguntas requieren el resultado de asset binding y otras pruebas.

Usa una fila por cloud-data assertion. Si una lleva un label de la lista y otra usa uno distinto, no combines los resultados en una sola insignia. Cada label debe poder rastrearse hasta su resultado.

Aplica la regla de actions en update manifests

Cuando el manifest es un update manifest, el label externo no puede ser c2pa.actions ni c2pa.actions.v2. Ambos producen assertion.cloud-data.actions. Registra el tipo de manifest mostrado, el label literal y el código exacto.

No asignes este resultado porque la palabra actions aparezca en otro punto. La condición depende a la vez del tipo de manifest y del label de la external assertion. Si la herramienta no muestra el tipo, déjalo sin confirmar.

La tabla puede incluir activo, label y tipo de manifest, label exterior, label, size, location, content_type, resultado de location si aparece, estado exacto, versión del validador y campos pendientes. Adjunta la salida completa.

Informa una conclusión limitada

Un pase estructural solo indica que la cloud-data assertion revisada cumplió estas reglas en esa ejecución. No verifica la afirmación referenciada, la confianza del firmante, la firma del claim ni una persona, pie, fecha, lugar o suceso. Un rechazo identifica un problema de conformidad; no dictamina que el medio sea sintético o engañoso.

Si analizas el activo con DeepFakeCheck, mantén la señal probabilística fuera de la tabla C2PA y vinculada al archivo exacto. La detección puede dar falsos positivos en medios auténticos y falsos negativos en medios sintéticos o alterados. DeepFakeCheck no valida assertions c2pa.cloud-data ni emite estos códigos.

Cierra el registro con el activo, la salida, la tabla, resultados separados de external references o asset binding, la publicación original y la decisión humana.

Fuentes

• C2PA, “C2PA Technical Specification, c2pa.cloud-data validation”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_c2pa_cloud_data_validation