Resumen

  • La revisión 02 del overview de vCon y la 04 del core son Internet-Drafts en desarrollo. Permiten que quien crea el contenedor defina el perímetro y omita cualquiera de sus cuatro secciones principales.
  • JWS prueba la integridad del payload y, dentro de una política de confianza, la posesión de la clave firmante. No certifica por sí sola la totalidad de la conversación, la identidad de las partes, el consentimiento vigente ni la exactitud de una inferencia.
  • Una sucesión de vCon enmendados conserva estados firmados. Para decidir sobre ellos hace falta además un registro que atribuya cada afirmación a una fuente, un alcance, una finalidad y una autoridad concreta.

Un auditor recibe tres objetos que parecen encajar. El primero contiene la llamada. El segundo añade una transcripción. El tercero corrige el nombre de una parte y adjunta un análisis de sentimiento. Cada versión está firmada; cada una apunta a su predecesora; el archivo externo recuperado coincide con su content_hash.

La secuencia parece una historia verificada hasta que se comparan las ausencias. No está la pista de uno de los participantes. La corrección de identidad viene de la empresa que hizo la transcripción, no del sistema que autenticó al usuario. El proveedor del análisis figura en vendor, pero faltan versión, idioma y configuración. La autorización de uso cubría archivo y control de calidad, no una decisión sobre el empleado.

La cadena demuestra quién comprometió qué bytes en cada etapa. No demuestra que la última etapa tenga la mejor descripción del mundo.

El IETF publica draft-ietf-vcon-overview-02, fechado el 30 de septiembre de 2026, y draft-ietf-vcon-vcon-core-04, fechado el 7 de septiembre de 2026, como trabajos del grupo Virtualized Conversations. Siguen siendo borradores, no RFC ni normas finales. Proponen un contenedor JSON capaz de cruzar plataformas, servicios de análisis y dominios de seguridad. Precisamente por cruzar fronteras, su receptor debe distinguir integridad, verdad y autoridad.

Verificar bytes no resuelve cinco preguntas distintas

La primera pregunta es si el payload cambió desde la firma: integridad. La segunda es qué identidad vincula la política de certificados con la clave: autenticación del firmante. La tercera pregunta qué sistema capturó o transformó cada objeto: procedencia. La cuarta contrasta la afirmación con la realidad: verdad semántica. La quinta decide si ese actor podía capturar, modificar, revelar o usar el dato: autoridad.

JWS resuelve directamente la primera y contribuye a la segunda. vCon ofrece lugares donde documentar la tercera. La cuarta y la quinta no viven dentro de un algoritmo de firma. Se puede firmar fielmente una transcripción equivocada. También se puede firmar un registro exacto y carecer de permiso para reutilizarlo.

La interfaz que resume todo en «verificado» convierte esas cinco decisiones en una delegación invisible. El estado correcto debe mostrar por separado integridad, identidad del firmante, cobertura, validación de afirmaciones y finalidad permitida.

Quien empaqueta decide dónde termina la conversación

El overview parte de una realidad incómoda: una conversación no siempre trae límites naturales. Un contenedor puede representar una grabación aislada o un recorrido que empieza en mensajes, pasa por una llamada y termina en correo. En SMS, el principio y el final se definen editorialmente.

Además, parties, dialog, attachments y analysis son opcionales. Una grabación sin lista de participantes sigue siendo una expresión válida. El core admite diálogos de transferencia, intentos incompletos y placeholders; una pista puede representar sólo una pierna de la sesión. Ningún objeto individual tiene por qué enumerar a todos.

La flexibilidad hace posible la minimización de datos y la adopción gradual. También impide inferir exhaustividad a partir de conformidad. La firma inmoviliza el perímetro escogido, pero no prueba que no exista un tramo omitido.

El receptor necesita una declaración de alcance: intervalos, canales, transferencias, plataformas, ausencias conocidas, política de captura y responsable. Después debe contrastarla con señal operacional independiente, como eventos de control, identificadores de mensajes, estado de grabadores o registros de otro dominio.

Cuando el overview llama al diálogo «ground truths», describe su condición de evidencia primaria frente al análisis derivado. No eleva una captura parcial a verdad absoluta. Una grabación puede ser auténtica y no abarcar la frase decisiva.

Los datos de una parte no equivalen a haber identificado a la persona

Un objeto de parte puede incluir nombre, teléfono, correo, SIP URI, DID, UUID y ubicación. validation permite declarar cómo se verificó la identidad sin incluir los datos de verificación. Eso limita exposición, pero traslada al receptor la evaluación del método.

Una firma sobre «validado con credenciales» prueba que el firmante hizo esa afirmación. No muestra qué credenciales, qué cuenta, cuándo, qué nivel de seguridad o si el vínculo sigue vigente. El registro de aceptación debe enlazar la afirmación con un evento, una referencia de evidencia, una hora y el dominio que responde por ella.

Un UUID persistente sólo tiene el significado que le concede su namespace. Sirve para correlacionar a un agente dentro de una organización; no se convierte en identidad universal al viajar. Y si una enmienda sustituye un alias por un nombre, hay que preguntar si su firmante tenía autoridad sobre identidad, no sólo si tenía una clave válida.

El archivo puede desaparecer mientras su hash sigue siendo perfecto

Los objetos de diálogo, adjunto y análisis pueden estar incluidos o referenciados por HTTPS. content_hash y SHA-512 permiten detectar que los bytes recuperados no son los comprometidos por el vCon firmado.

Pero el core deja fuera de alcance el almacenamiento, el control de acceso y el intercambio de credenciales para contenido externo. Una respuesta 403 significa que el receptor no puede inspeccionar la prueba; 404 puede significar que la retención la eliminó. En ambos casos, el hash continúa identificando exactamente algo que ya no está disponible.

Conviene guardar tres estados: integridad de la referencia, disponibilidad efectiva y autorización de uso. Ninguno sustituye al otro. También quedan fuera de esa luz verde la seguridad del fichero, su decodificación y su cobertura temporal.

Si una decisión debe ser auditable durante años, la organización tiene que escoger entre archivar los bytes, mantener un acceso controlado duradero o aceptar una fecha de caducidad probatoria. Conservar sólo el hash guarda un compromiso, no la capacidad de volver a examinar el hecho.

Un nombre de proveedor aporta procedencia, no una calificación

El objeto analysis contempla transcripción, traducción, resumen, sentimiento e informes. Como el core no normaliza todos los formatos, exige vendor y permite product y schema. El overview admite que distintas implementaciones producen resultados con calidad e interpretación diferentes.

Esos campos ayudan a encaminar y atribuir datos. Pueden no revelar modelo, reglas, prompt, idioma, umbral, preprocesamiento o corrección humana. Tampoco garantizan que el análisis se ejecutara sobre los mismos bytes que ahora resuelve la URL.

Una inferencia necesita un recibo separado: hashes e índices de entrada, proveedor, producto, esquema, versión del modelo o reglas, configuración, locale, hash de salida, significado de la confianza, revisión humana y finalidad permitida. Este registro es una propuesta operativa de Daniel Kade, no un requisito normativo de los borradores.

Guardar la salida firmada sigue siendo útil: conserva lo que el sistema produjo. El error aparece cuando se transforma esa procedencia en exactitud o en permiso para tomar una decisión de alto impacto.

El consentimiento no hereda la duración de la firma

Los textos de vCon reconocen que consentimiento y procedencia dan contexto al registro. El privacy primer y el draft sobre lawful basis exploran finalidades y jurisdicciones. No convierten una firma en certificado universal de cumplimiento.

Una afirmación sobre consentimiento necesita sujeto, método, fecha, política mostrada, finalidad, jurisdicción y estado de retirada. Capturar, analizar, compartir y conservar pueden tener bases distintas; en algunos entornos la base no será el consentimiento. La norma aplicable debe decidirse localmente y este análisis no ofrece asesoramiento jurídico.

La firma autentica el registro histórico de la afirmación. No decide si cubre el uso actual. Cuando una persona retira su consentimiento o cambia la política, la firma antigua debe seguir siendo criptográficamente válida: el pasado no debe reescribirse. Lo que cambia es la autorización presente y las acciones downstream.

Enmendar crea una historia, no un árbitro

Un vCon firmado no se modifica sin invalidarlo. La propuesta crea una nueva versión, copia profunda de la anterior con adiciones o cambios, y la enlaza mediante amended al UUID previo, opcionalmente con URL y hash. Distintos dominios pueden firmar etapas de la vida del expediente.

La cadena permite verificar estados anteriores, siempre que sigan disponibles. No garantiza que la copia profunda conservara todo, que los índices mantengan significado, que la corrección sea verdadera o que el nuevo dominio pueda alterar ese campo. El receptor debe recuperar al predecesor, validarlo, comparar el cambio y aplicar autoridad por clase de afirmación.

La redacción ofrece una advertencia paralela. El core deja el método fuera de alcance y atribuye su garantía a la entidad que produce y firma la versión redacted. Esa entidad puede ignorar datos en un adjunto, una derivación o una extensión. Su firma identifica la responsabilidad; no inspecciona automáticamente todos los lugares donde vive la información.

Por eso «última versión firmada» no debe convertirse en «verdad vigente». Un proveedor puede estar autorizado a añadir una transcripción y no a corregir identidad. Un controlador puede redactar para un destinatario y no eliminar la fuente original.

Las extensiones obligan a decidir por operación

Una extensión puede añadir parámetros, cambiar significados o deprecar campos. Las incompatibles deben figurar en critical; si un procesador no las entiende, no debe continuar salvo para rechazar o informar.

La compatibilidad depende de la tarea. Un transcriptor quizá ignore un campo nuevo sin afectar su trabajo. Un servicio de redacción puede necesitar conocer cualquier campo que contenga información personal. Así, el mismo vCon se acepta para transcribir y se rechaza para redacted.

Registrar extensiones presentes, lista critical, versión del registro, software, operación y motivo de ignorar o bloquear. «JSON válido» es un resultado de parseo, no de comprensión.

Un registro de evidencia conserva las fronteras

Por cada uso, enlazar UUID, hash y forma del vCon; alcance y exclusiones; sistemas y dominios contribuyentes; firmante, cadena y política; evidencia de las partes; cobertura de captura; recuperación y permisos externos; entradas y configuración del análisis; finalidad; capacidades de extensión; predecesor y diff; decisión, responsable y reversión.

Separar hechos observados de afirmaciones transportadas. «Coincide SHA-512» fue observado. «La identidad fue validada» sigue siendo una afirmación hasta enlazar el evento. «Puede usarse para control de calidad hasta tal fecha» es una resolución local.

La ruta de aceptación queda así: alcance -> recuperación -> bytes -> firmante -> autoridad -> extensiones -> linaje -> afirmaciones -> finalidad -> registro -> retirada.

En el caso inicial, la firma no falla. La decisión sensible espera la pista ausente; el cambio de identidad se aísla; el sentimiento queda como dato no decisorio; la finalidad nueva necesita autorización. El método conserva la evidencia criptográfica sin convertirla en poder general.