Estados de un manifest C2PA: Well-Formed, Valid y Trusted

Conserva el archivo y el resultado completo

Abre el archivo conservado en un validador compatible con C2PA y guarda toda la salida, no solo una insignia. Anota nombre o URL de origen, hora de obtención, validador y versión, label del active manifest y cada status code mostrado. Esta tabla es una propuesta operativa del artículo, no un formato exigido por C2PA.

Delimita la pregunta: qué validation state cumple el active manifest en esta ejecución y qué controles respaldan ese estado. La relación es jerárquica. Todo manifest Trusted también es Valid, y todo Valid también es Well-Formed. La relación inversa no se puede asumir.

Separa el estado del manifest del estado del asset y de las afirmaciones sobre el suceso. C2PA considera Valid un asset cuando las partes cubiertas por content bindings no han cambiado desde que se produjo el active manifest y ese manifest es Valid o Trusted. Esa conclusión se limita a bytes cubiertos y procedencia; no confirma el pie, la identidad, el lugar ni el hecho representado.

Comprueba primero los requisitos de Well-Formed

Un manifest es Well-Formed cuando su contenido cumple los requisitos normativos comprobados por el validation process, contiene solo assertions permitidas para su tipo, sus assertions cumplen sus requisitos y los ingredients presentes cumplen los suyos. Usa una fila para cada grupo y copia el resultado exacto del validador.

Si la herramienta no muestra un detalle, escribe “no mostrado” en vez de inferir un pass. Well-Formed describe estructura y conformidad con reglas. Es requisito para Valid, pero no indica que el manifest siga intacto desde la firma, que la claim signature o su periodo hayan pasado, ni que el firmante sea trusted.

Añade las comprobaciones necesarias para Valid

Un manifest Valid debe ser Well-Formed. La validación también debe determinar que no fue modificado después de firmarse. La claim signature debe recibir claimSignature.validated y la comprobación del periodo de validez debe recibir claimSignature.insideValidity.

La credencial del firmante no puede quedar rechazada con signingCredential.ocsp.revoked ni signingCredential.ocsp.unknown. Registra firma, tiempo y revocación en líneas separadas. Responden preguntas técnicas distintas aunque todas formen parte de Valid.

Cuando el manifest es Valid, C2PA permite atribuir el claim al claim generator identificado en claim_generator_info. Copia el field visible sin convertir la atribución en una afirmación de que la herramienta presenció el suceso o comprobó todo el contenido de una assertion.

Exige confianza en el firmante para usar Trusted

Trusted añade una condición a Valid: la signing credential debe recibir signingCredential.trusted. Si el validador muestra Valid sin ese success code, no eleves el estado porque el nombre del publisher o del software sea conocido.

La confianza depende también de la configuración del validador. La especificación exige listas de Extended Key Usage aceptados y trust anchors X.509. Para c2pa-kp-claimSigning, los anchors incluyen la C2PA Trust List, aunque una lista puede estar vacía y el usuario puede configurar anchors adicionales. Conserva la versión y el trust context visibles.

Una tabla útil separa manifest label, requisitos Well-Formed, integridad de firma, periodo de validez, revocación, signer trust, estado final y asuntos pendientes. Así, la palabra “trusted” no oculta las pruebas que la produjeron.

Separa estados, integridad y afirmaciones reales

No mezcles las listas de status codes success, informational y failure con los validation states. Los códigos registran controles individuales; Well-Formed, Valid y Trusted se derivan de sus condiciones. Separa también Valid manifest de Valid asset, que añade el resultado del content binding.

Si analizas el archivo con DeepFakeCheck, guarda la señal probabilística en otro apartado. La detección automática puede producir falsos positivos sobre medios auténticos y falsos negativos sobre medios sintéticos o alterados. DeepFakeCheck no asigna estados C2PA ni emite sus códigos.

Un riesgo bajo no convierte un manifest Well-Formed en Valid o Trusted. Un manifest Trusted tampoco demuestra el suceso, el pie ni la identidad del hablante. Contrasta esas afirmaciones con la publicación original y fuentes independientes. Cierra el registro con archivo, salida completa, controles requeridos, trust context, resultado de content binding si existe y decisión tomada.

Fuentes

• C2PA, “C2PA Technical Specification, Validation states”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validation_states