Resumen

  • verified=true en RFC 9796 declara que quien incluyó un campo concreto de Call-Info verificó la información representada allí. El receptor debe confiar de forma autenticada en ese actor.
  • La indicación no se extiende automáticamente a todos los datos del llamante, al motivo escrito, a la conversación ni al resultado. Si falta, tampoco demuestra fraude: falta la señal de verificación definida por RFC 9795.
  • El hash de integrity compara bytes. Identidad, vigencia, disponibilidad, renderizado, atención humana y legitimidad necesitan recibos diferentes.

El fraude más convincente no siempre inventa una identidad completa. A veces basta con apropiarse de la autoridad visual de una palabra. «Verificado» ocupa muy poco espacio en una pantalla y parece cerrar todas las preguntas anteriores: firma, origen, intención y seguridad. RFC 9796 evita esa expansión semántica si se lee con cuidado.

La norma define cómo representar Rich Call Data en el encabezado SIP Call-Info. Añade los parámetros call-reason, verified e integrity, además del propósito jcard. Su formulación central es deliberadamente estrecha: verified=true significa que la parte que insertó ese campo realizó con éxito la verificación de la información representada. La capacidad del receptor para creerlo depende de la relación de confianza con la parte de la que recibió la solicitud.

No es una debilidad. Es un contrato de custodia. Un proveedor de terminación puede validar evidencia que el teléfono no sabe procesar y entregar un resultado utilizable. Pero el resultado sigue teniendo autor, alcance y frontera.

El sistema cambia de testigo a mitad del camino

RFC 9795 protege Rich Call Data en un PASSporT. RFC 8225 define ese token firmado, sobre la familia JWT de RFC 7519, y RFC 8224 integra la identidad STIR en SIP. El verificador de red puede comprobar la firma, la ruta de certificados, los campos y los digestos referenciados.

Después ocurre una traducción. RFC 9796 permite que el proveedor coloque la información aceptada en Call-Info para un dispositivo autenticado en una interfaz de usuario-red confiable. El teléfono ya no declara «validé el PASSporT». Declara, en el mejor de los casos, «confío en el proveedor que me entregó esta conclusión».

Por eso conviene conservar una secuencia explícita:

  1. un origen presenta datos candidatos;
  2. llega un PASSporT;
  3. su firma y certificado se validan;
  4. se comparan las afirmaciones y los digestos;
  5. una política local acepta el resultado;
  6. un actor identificado lo transforma en campos Call-Info;
  7. el terminal autentica a ese actor;
  8. recupera recursos externos;
  9. comprueba sus hashes;
  10. decide qué mostrar;
  11. la persona lo ve y actúa;
  12. hechos posteriores confirman o desmienten la legitimidad y el resultado.

La palabra «verificado» solo ocupa una parte de esta escalera. Convertirla en la escalera completa destruye la posibilidad de auditar dónde falló una decisión.

Los campos de la tarjeta no comparten automáticamente su prueba

El sistema base de RFC 3261 permite transportar Call-Info, pero un nombre de visualización ordinario no es por sí mismo un hecho autenticado. La ficha enriquecida puede combinar nombre, fotografía, logotipo, icono y motivo. RFC 9796 exige coherencia entre representaciones que se solapan, como From, P-Asserted-Identity y los datos jCard.

jCard procede de RFC 7095 y usa el modelo JSON normalizado por RFC 8259. Para RCD se espera un único objeto de entidad. Esa limitación ayuda a evitar que una tarjeta sugiera varias identidades incompatibles, pero no transforma todos sus atributos en una sola afirmación criptográfica.

La tarjeta puede viajar en una URI data:, en un cuerpo MIME referenciado con el esquema cid: de RFC 2392, o desde una fuente cuya integridad pueda comprobarse, por ejemplo HTTPS ligado a un dominio validado. Cada opción crea otro patrón de custodia: datos dentro del mensaje, datos en otra parte del mensaje o datos obtenidos de un servidor.

También existe una forma mínima para indicar un nombre verificado mediante una URI data: nula y purpose=jcard. La ausencia de un objeto visual grande no elimina la afirmación. Al contrario: obliga a saber qué actor puso el indicador y a qué representación exacta se refería.

El digest no puede prometer que la imagen llegó a tiempo

integrity vincula una URI a un algoritmo y un valor hash. Los implementadores deben admitir SHA-256, SHA-384 y SHA-512. Si el cálculo coincide, el terminal sabe que los bytes recuperados son los bytes descritos. Esa conclusión soporta una defensa técnica concreta.

No dice si el servidor estaba disponible durante el timbrado, si la imagen seguía vigente, quién la eligió, si la política permitió mostrarla o si el usuario la miró. Tampoco garantiza que el nombre y la imagen describan una conversación legítima. La igualdad de bytes no es igualdad de intenciones.

El call-reason tiene un límite parecido. Es opcional, breve, puede truncarse y su visualización no está garantizada. La norma no define cómo lo establece el llamante. «Confirmación de cuenta» puede ser una descripción enviada; no es una prueba de que exista una cuenta ni de que la solicitud posterior sea segura.

Los marcadores protocolarios siempre necesitan políticas alrededor. RFC 7852, por ejemplo, registra una semántica de prioridad de recursos SIP para servicios de emergencia; esa semántica no reemplaza la autorización que decide quién puede usarla. El mismo principio impide que una marca RCD absorba identidad, prioridad, intención y resultado.

Un intermediario no debe retocar la evidencia hasta volverla irreconocible

RFC 9796 pide una única versión coherente de RCD en Call-Info. Los participantes posteriores no deben modificarla ni añadir campos contradictorios. Sin STIR u otra protección, no se puede suponer que las alteraciones a través de redes interconectadas no confiables sean detectables.

Un cambio de nombre o fotografía después de la verificación no es un ajuste inocente. Separa la presentación de la prueba que debía sostenerla. Si una red transforma datos, su recibo debe incluir la entrada, la política, el actor, el campo de salida y el destinatario confiable.

Los registros públicos solo prueban el estado del estándar. La versión de texto, el XML canónico, la ficha informativa, las erratas, el historial del IETF y el registro IANA de parámetros SIP permiten comprobar la especificación. No son recibos de despliegue para ningún operador o fabricante.

La idea de código en ejecución exige localizar el componente que ejecutó la comparación. La especificación inicial mínima coordina un significado compartido sin impedir decisiones locales más exigentes. Y separar las capas de realidad evita confundir una señal de interfaz con una verdad social total.

RFC 9796 hace algo valioso: permite que la verificación sobreviva al salto desde una infraestructura compleja hasta un terminal sencillo. La responsabilidad consiste en no borrar la etiqueta de custodia durante ese salto.

Fuentes