Resumen

  • La revisión 00 de terms.txt combina reglas por ruta con solicitudes firmadas, declaraciones de finalidad, delegaciones de usuario, vales de pago y recibos emitidos por el origen.
  • El límite está escrito en el propio texto: la firma atribuye una declaración y el recibo una entrega concreta, pero ninguno verifica la conducta posterior.
  • Daniel Kade propone un registro de obligaciones de acceso para mantener separados el control previo, la auditoría y el contrato. Es análisis editorial, no una exigencia del IETF.

El 403 cuenta una historia más precisa que el 402

Cuando una solicitud no satisface las condiciones, la revisión 00 de terms.txt no intenta convertir el código 402 en un nuevo sistema de cobro. Usa 403 y añade un documento Problem Details que distingue firma inválida, repetición, propósito denegado, nivel de uso excesivo, delegación ausente o pago requerido. Tampoco elige 401, porque el intercambio no ofrece el campo WWW-Authenticate que ese estado presupone.

Es una decisión importante de gobernanza técnica. Se apoya en la semántica HTTP existente y pone el motivo específico en una estructura aparte. El servidor conserva la decisión sobre su propio recurso; el protocolo no declara que una negativa sea una sanción universal ni que un pago resuelva por sí solo las obligaciones futuras.

Antes de llegar a ese punto, el origen publicaría /.well-known/terms.txt, siguiendo el mecanismo de URI conocidas. En bloques por ruta podría admitir, cobrar o rechazar distintos propósitos, fijar un límite de reproducción y exigir que un usuario delegue un ámbito concreto. El fichero pretende dar más precisión que robots.txt, cuyas reglas son solicitudes a los rastreadores y no autorización de acceso.

Lo que sí puede comprobar el origen

El cliente automatizado usaría el borrador separado de Web Bot Auth y las firmas de mensajes HTTP. Su campo Access-Intent declararía finalidad y nivel de uso. Si las condiciones lo requieren, adjuntaría una delegación vinculada al agente o un vale de pago de un solo uso. La firma cubriría esos campos y el URI completo.

El servidor puede comprobar hechos presentes en su frontera: que una clave publicada bajo el identificador resuelto firmó, que la solicitud está dentro de la ventana temporal, que el nonce no se repite, que la declaración no fue alterada, que la delegación vale para ese origen y agente, y que el vale no ha sido gastado. Tras esas comprobaciones puede entregar o negar.

Pero reconocer una clave no equivale a conocer a la persona jurídica que opera el bot. El borrador de Web Bot Auth crea continuidad para un identificador y permite limitarlo o bloquearlo. Una garantía adicional sobre la empresa requeriría otro registro o una relación de confianza. Del mismo modo, terms.txt deja fuera de alcance cómo el origen confía en un proveedor de identidad o en un servicio de liquidación.

Declarar, entregar y usar son tres hechos

El texto divide correctamente la evidencia. La primera capa es ejecutable antes de la entrega. La segunda es auditable después: una declaración firmada puede compararse con la conducta que resulte observable. La tercera es contractual: una vez que los bytes salen del origen, HTTP no sabe si alimentaron un índice, un resumen, un modelo o una copia completa.

Una firma demuestra que el titular de la clave produjo una declaración intacta. No demuestra que el propósito declarado sea verdadero. El Access-Receipt demuestra que el origen entregó una representación bajo unas condiciones identificadas. No acompaña cada copia posterior ni inspecciona su uso.

La regla de caché HTTP hace visible esa estrechez. Un recibo está ligado a una sola solicitud firmada. Si un intermediario sirviera la respuesta almacenada a otro solicitante, el recibo seguiría nombrando la primera petición. Por eso el borrador exige Cache-Control: no-store en respuestas con recibo. La atribución por solicitud sacrifica reutilización; un diseño posterior tendría que resolver esa tensión de forma explícita.

También hay un borde frágil en el archivo de condiciones. Un error de sintaxis invalida terms.txt completo, y el cliente debe tratarlo como si no existieran condiciones. Una organización que dependa del mecanismo necesita control de versiones, validación previa, publicación atómica y prueba desde fuera. Publicar un fichero no basta para saber cuál recibió un agente.

La novedad aún carece de mandato formal

El registro en Datatracker dice que se trata de un Internet-Draft individual, sin flujo asignado y sin posición formal en el proceso del IETF. El historial registra una publicación manual el 11 de septiembre de 2026. No hay adopción de grupo, director de área responsable, evaluación del IESG ni RFC.

Aunque la cabecera aspira a Standards Track, Datatracker no muestra todavía un estado RFC previsto. Los borradores de grupo sobre vocabulario de preferencias de IA y su asociación con contenido HTTP son trabajos distintos. No transfieren su legitimidad procesal a esta propuesta.

La implementación de referencia tampoco debe leerse como conformidad. El documento describe 24 pruebas y medidas, pero reconoce que la versión v0.1 es anterior y difiere en el URI cubierto, los estados HTTP, el formato de tokens, la identidad vinculada, los campos del recibo, el vale, la política de caché y la relación de enlace. Es evidencia de que alguien ejecutó una idea cercana, no de que dos implementaciones reproduzcan la revisión 00.

Un registro que sobreviva a la interfaz

Daniel Kade propone un registro de obligaciones de acceso. Cada entrada uniría origen y ruta, versión y resumen criptográfico de las condiciones, finalidad y uso declarados, identificador del agente y límite de identidad, emisor y alcance de la delegación, autoridad de pago, decisión previa, resumen del contenido, identificador del recibo, observaciones posteriores, obligación contractual, responsable de disputa, vencimiento, revocación y sustitución.

La idea no es vigilarlo todo. Es impedir que una interfaz limitada se convierta en una afirmación total. El Policy Mirror de Heng Lu coloca la frontera entre evidencia y autoridad en primer plano. La Minimum Initial Specification pide un núcleo común pequeño que no anule decisiones locales. Why BTW Media Exists aporta la disciplina periodística: registrar la propuesta sin vender como hecho el futuro que promete.

Fuentes

  1. Ficha Datatracker de terms.txt
  2. Historial de terms.txt
  3. Revisión 00 de terms.txt
  4. Borrador Web Bot Auth
  5. Vocabulario de preferencias de uso de IA
  6. Asociación de preferencias de IA con HTTP
  7. RFC 9309 — Robots Exclusion Protocol
  8. RFC 9421 — HTTP Message Signatures
  9. RFC 9457 — Problem Details
  10. RFC 9110 — Semántica HTTP
  11. RFC 9111 — Caché HTTP
  12. RFC 8615 — URI conocidas
  13. RFC 8126 — Procedimientos de registro de IANA
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists