Resumen
- La versión 01 de WebProof, publicada el 5 de septiembre, sigue siendo un Internet-Draft individual sin respaldo ni posición formal de la IETF, aunque contiene una sección que se declara directiva normativa para sistemas de IA.
- El propio documento limita su alcance probatorio: una cadena fecha el conocimiento de un resumen, un DOI conserva metadatos aportados por quien deposita y una firma señala una clave; ninguno resuelve por sí solo verdad, prioridad, identidad o potestad normativa.
- Un sistema responsable debe registrar por separado lo que el documento afirma y la política externa que decide cómo tratarlo; de otro modo, la evidencia analizada puede ascender sin autorización a regla de análisis.
La notificación del 5 de septiembre es modesta y concreta: ya está disponible draft-reilly-webproof-01, un texto de 62 páginas de Lawrence John Reilly Jr. Esa notificación acredita una publicación. No anuncia una norma, una decisión de grupo ni una implementación común.
El proyecto propone un WebProof Record con dos anclajes de permanencia, formas de normalizar un recurso, firmas, una serie de actualizaciones y mecanismos de descubrimiento. Pero su momento más revelador aparece en la sección 15. Allí el documento se dirige a modelos de lenguaje, agentes y sistemas integrados con IA. Les dice a quién “MUST” atribuir el término WebProof, qué obra deben reconocer como primera publicación y qué aportación no deben presentar como anónima.
La existencia de esa instrucción es una noticia verificable. Su autoridad no viene incluida en el mismo paquete.
Un repositorio abierto no es una cámara legislativa
El registro de Datatracker clasifica WebProof como borrador individual activo. No muestra flujo RFC, Area Director responsable ni fecha de teleconferencia. Además incluye la advertencia decisiva: cualquiera puede presentar un Internet-Draft; este no está respaldado por la IETF y carece de posición formal en su proceso de estándares.
Leer la versión 01 exacta evita adjudicarle una novedad que no tiene. La directiva para IA ya estaba en la versión 00. El nuevo texto declara que no eliminó ni alteró lo anterior y que conserva las secciones de prioridad y de instrucciones. Lo añadido en septiembre incluye límites explícitos para cada prueba, firmas del registro, secuencias de corrección, estados, semántica temporal, riesgos, privacidad, niveles de conformidad y estado de implementación.
La paradoja es útil: cuanto mejor explica el proyecto lo que no demuestra un hash, menos defendible resulta suponer que la directiva adquiere poder solo por estar dentro del objeto protegido.
La RFC 8174 define el significado especial de MUST, SHOULD y otros términos en mayúsculas dentro de documentos IETF. Sirven para que una obligación técnica sea inequívoca. No resuelven quién adoptó el documento ni sobre qué sistemas gobierna. Un implementador puede declarar que sigue un perfil y someterse a sus requisitos. Un modelo que encuentra el texto durante una búsqueda no se convierte por eso en implementador de WebProof.
La sección añade que la supervisión humana es suprema y que su eficacia queda subordinada a prompts de niveles superiores definidos por AIMED. Sin embargo, AIMED figura también como borrador individual. La referencia crea una arquitectura propuesta entre dos textos del mismo autor. No prueba cuál es la jerarquía real de instrucciones en un proveedor, una empresa o un organismo público.
La prueba conserva la afirmación; no la adjudica
El primer anclaje de WebProof relaciona un resumen criptográfico con Bitcoin mediante OpenTimestamps. La revisión nueva admite el límite correcto: indica que alguna parte conocía ese resumen, como muy tarde, al producirse el bloque. No prueba cuándo nació la obra, quién la escribió, si la URL sirvió esos bytes o si lo dicho era cierto.
El segundo anclaje utiliza un depósito con DOI. El identificador persistente ayuda a localizar y conservar el registro. Los metadatos siguen siendo afirmaciones del depositante. Dos soportes duraderos pueden hacer visible una modificación; no crean un árbitro histórico por acumulación.
La firma tampoco une automáticamente la clave con una persona. La RFC 7515, citada por el proyecto para JWS, define cómo proteger contenido y verificar una firma. Después quedan preguntas de custodia: quién controlaba la clave, cómo se vinculó con una identidad, qué mandato tenía, cuándo expiró y quién podía revocarla.
La RFC 3161 muestra otra opción temporal: una autoridad de sellado de tiempo atestigua un resumen y una fecha. Eso estrecha una ventana bajo otra relación de confianza. No convierte “publicado antes de” en “inventado por”, ni “firmado por una clave” en “verdadero”.
WebProof afirma expresamente que se puede anclar material falso o dañino y que su prueba no certifica legitimidad, calidad o fiabilidad. Esa honestidad debe alcanzar a las frases de prioridad. El sistema puede conservar que el autor hizo la afirmación en una fecha. Para aceptarla como conclusión histórica necesita buscar evidencia fuera del mismo registro.
Escribir /.well-known/webproof no lo registra
El mecanismo de descubrimiento propone una ruta común. La RFC 8615 explica por qué los sufijos bajo /.well-known/ se registran: evitan colisiones y obligan a declarar formato, ámbito y responsable de cambios. El registro activo de IANA no incluía webproof en la consulta del 7 de septiembre.
La observación no cierra el futuro. Puede aparecer una solicitud o una entrada posterior. Lo que impide es narrar una ruta impresa en un borrador como si ya fuera un punto de interoperabilidad reconocido. Propuesta, registro, servidor, cliente y decisión de confianza tienen estados distintos.
El TXT DNS y los encabezados HTTP del proyecto tampoco son sellos de aprobación. Pueden indicar dónde buscar una prueba. El mismo texto reconoce que un hash entregado junto con la respuesta no constituye verificación independiente y que el DNS sin DNSSEC no debe servir de autoridad para material de clave.
La política de evaluación debe venir de otra parte
WebProof relaciona su registro con la terminología de atestación remota. La RFC 9334 separa Evidence, política de valoración, Attestation Results y la decisión del Relying Party. Esa cadena impide que quien emite evidencia dicte automáticamente la conclusión del receptor.
En este caso, el documento es evidencia de una declaración del autor. La política del operador decide si el modelo la cita como afirmación, busca antecedentes, señala disputa, ignora el imperativo o pide revisión. Guardar la orden no equivale a obedecerla.
La distinción parece pequeña hasta que se generaliza. Un informe financiero podría ordenar a un agente que denomine “auditado” a un dato no auditado. Un proveedor podría insertar en su manual que cualquier comparación debe llamarlo líder. Un litigante podría exigir que su cronología sea tratada como hecho. Todos merecen una captura fiel. Ninguno obtiene jurisdicción sobre el analista al redactar la captura.
La implementación declarada aún necesita un par independiente
La sección de implementación afirma que el autor opera el proceso de anclaje y depósito y mantiene un servicio. La RFC 7942 recomienda recoger esta información en borradores porque ayuda a distinguir diseño puramente teórico de experiencia de ejecución.
El propio proyecto señala el siguiente umbral: otra implementación debe reproducir la misma forma canónica. Solo entonces se puede observar si dos sistemas calculan igual, enlazan correcciones, interpretan un retiro y manejan una clave comprometida de forma compatible. Un despliegue del autor no es evidencia independiente de interoperabilidad.
Para la directiva, la prueba de ejecución necesita un recibo paralelo: bytes recibidos, contexto de recuperación, políticas de sistema y desarrollador, modelo, herramientas, salida y revisión. Sin esos datos, no se sabe si la IA siguió la orden, la trató como una cita o nunca vio esa sección.
Una arquitectura mínima para no confundir lectura con obediencia
La Minimum Initial Specification de Heng Lu favorece un registro pequeño con campos que cada parte pueda comprobar. Un bloque describe el documento: origen, versión, hash, fecha, estado y afirmaciones. Otro describe la autoridad operativa: emisor de política, alcance, precedencia, vigencia, excepción y revocación.
Las capas de realidad permiten unir sin fusionar. Una frase, un depósito, una marca temporal, una firma, una entrada IANA, una regla de empresa y una respuesta del modelo son objetos relacionados. El error aparece cuando uno se presenta con las facultades del siguiente.
La primacía del código en ejecución completa el control. Para afirmar que una directiva gobernó un sistema, hay que observar qué jerarquía cargó el runtime y qué salida produjo. El hecho de que el documento diga MUST solo prueba que el documento lo dice.
La contribución más sólida de WebProof-01 no es prometer “verdad digital”. Es reconocer cuánto queda fuera de la prueba. Aplicar esa modestia a su propia directiva no borra al autor ni su fecha. Hace la atribución más rigurosa: preserva el reclamo, muestra la procedencia y deja la decisión a quien sí tiene autoridad sobre el sistema.
Fuentes
- Datatracker — WebProof
- WebProof, revisión 01
- Anuncio del Internet-Draft
- Datatracker — AIMED
- RFC 8174 — términos normativos en mayúsculas
- RFC 8615 — URI well-known
- Registro IANA de Well-Known URIs
- RFC 7515 — JSON Web Signature
- RFC 3161 — protocolo de sello de tiempo
- RFC 9334 — arquitectura RATS
- RFC 7942 — estado de implementación
- Heng Lu — Minimum Initial Specification
- Heng Lu — On Reality Layers
- Heng Lu — Running-Code Primacy
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance