Auditoria de RSL 1.0: una capa de licencias que sale sin precios

Todo protocolo de pagos que auditamos responde una pregunta: cuanto. RSL es el primer estandar que intenta responder la otra — que puede hacer el agente con lo que acaba de comprar. Pasamos un dia midiendolo, y el campo de precio esta vacio.

Cuando desarmamos la enforcement en el edge de Cloudflare y AWS, dejamos un hueco abierto. AWS lo dijo sin vueltas: la monetizacion "les dice a los agentes cuanto pagar, pero no que tienen permitido hacer con el contenido". El puntero que ambos edges dieron para esa mitad faltante fue RSL, Really Simple Licensing.

RSL merece una mirada seria por una razon que no tiene nada que ver con la politica editorial. Es el unico estandar que encontramos que pone las reglas de acceso, el precio y el protocolo de pago en un solo documento legible por maquina — y el protocolo de pago que nombra es x402. Eso lo vuelve directamente estructural para cualquier cosa que pague por uso sobre HTTP.

Asi que lo auditamos como auditamos todo aca. Leimos la especificacion, verificamos sus registros, crawleamos la web abierta buscandolo, bajamos cada documento de licencia vivo que pudimos encontrar y manejamos sus license servers. Todas las mediciones son del 22 de agosto de 2026 y son reproducibles.

Que especifica realmente RSL 1.0

La especificacion RSL 1.0 lleva el estado "Recommendation" y fecha de publicacion 2025-12-10. Define un namespace permanente, https://rslstandard.org/rsl, y un media type, application/rsl+xml. Se apoya explicitamente en RSS y en el Robots Exclusion Protocol (RFC 9309).

El nucleo es un vocabulario XML chico. Un elemento <content> identifica un asset por URL y puede llevar un atributo server que apunta a un license server. Adentro, uno o mas elementos <license> combinan <permits>, <prohibits>, <payment>, <reporting> y <legal>.

El vocabulario de uso es la parte que le importa a los publishers: all, ai-all, ai-train, ai-input, ai-index, search. La distincion entre ai-train y ai-input es la que importa para agentes — entrenar sobre una pagina es un acto distinto de leerla en tiempo de inferencia para responder una pregunta, y RSL es uno de los pocos vocabularios que permite tarifarlos por separado.

El vocabulario de pagos es mas amplio que cualquier cosa en la conversacion de pay-per-crawl: <payment> toma un type de purchase, subscription, training, crawl, use, contribution, attribution o free. El precio va en <amount> con un atributo currency requerido. Los terminos pueden referenciarse desde un marco compartido con <standard> o delegarse a la pagina propia del publisher con <custom>.

El discovery es deliberadamente plural. Se definen cinco canales: una directiva License: en robots.txt, un header HTTP Link con rel="license", un <link> HTML o un <script type="application/rsl+xml"> inline, un modulo RSS, y metadata embebida en archivos de media.

Encima viven tres protocolos de red opcionales. El Open License Protocol (OLP) es una extension de OAuth 2.0: POST /token con grant client_credentials devuelve un access_token cuyo token_type es el string License, mas /introspect segun RFC 7662 y /key para llaves de cifrado como JWK. El Crawler Authorization Protocol (CAP) define Authorization: License <token> y las respuestas 401 / 402 / 403 / 503 alrededor. El Encrypted Media Standard (EMS) cubre assets marcados encrypted="true".

La seccion 4.10 es donde esto toca nuestro stack. Un servidor "MAY responder con un status 401 Unauthorized o 402 Payment Required cuando el acceso a un recurso depende de obtener una licencia", y esa respuesta deberia llevar o un body application/rsl+xml inline o un header Link apuntando a la licencia vigente. Es el mismo 402 que venimos mapeando desde el primer recorrido por x402, usado para devolver terminos en lugar de un challenge de pago.

La costura con x402

El elemento que nos hizo empezar esta auditoria es <accepts>. Anuncia los metodos de pago que un cliente MUST usar para satisfacer los terminos que lo contienen, y la especificacion es inusualmente concreta sobre uno de ellos: "Para el protocolo x402, esto MUST ser application/x402+json". Vale leer el ejemplo de la propia spec con atencion.

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="/">
    <license>
      <payment type="crawl">
        <standard>https://example.com/licenses/pay-per-crawl</standard>
        <accepts type="application/x402+json">
          { "scheme": "deferred",
            "network": "example-network-provider",
            "resource": "https://example.com/" }
        </accepts>
      </payment>
    </license>
  </content>
</rsl>

Hay tres cosas mal en esta imagen, y ninguna es un typo.

Primero, el media type no existe del otro lado. Clonamos x402-foundation/x402 en HEAD 230e6a9, del 21 de agosto de 2026. El string application/x402+json aparece cero veces en todo el arbol. Tambien rslstandard, y tambien "Really Simple Licensing". RSL acuño un media type en nombre de x402, lo declaro obligatorio, y x402 nunca oyo hablar de el. Ninguno de los dos esta registrado en IANA tampoco, cosa a la que volvemos mas abajo.

Segundo, los valores del ejemplo no coinciden con el protocolo que nombra. El network es el string placeholder example-network-provider, cuando x402 indexa redes por identificador CAIP-2. Y el scheme es deferred: en el arbol de x402 que clonamos, el literal "exact" aparece 1.526 veces, "upto" 100 veces, "batch-settlement" 55 veces — y "deferred" dos veces. El ejemplo estrella de integracion esta escrito contra el nombre de scheme menos presente en el codigo.

Tercero, y lo mas estructural, RSL tiene dos campos de precio que no pueden expresar lo mismo. <amount> exige un codigo de moneda ISO 4217. x402 tarifa en unidades atomicas de un activo especifico en una cadena especifica. No hay mapeo definido entre ambos, y la respuesta de RSL es patear la pelota: el pricing autoritativo "MAY ser provisto dinamicamente por el protocolo de pago en runtime".

Es la misma linea de falla que encontramos en la auditoria de OpenTelemetry GenAI: una especificacion que modela dinero como un decimal en moneda fiat, atornillada a una capa de settlement que modela dinero como un entero de unidades de token en una cadena nombrada. Dos ledgers, una clave de join, ninguna conversion definida.

El crawl: 1.013 dominios, cinco directivas

Las especificaciones son baratas. Queriamos el numero de deployment, asi que lo medimos.

Tomamos los primeros 1.000 dominios del Majestic Million mas 50 publishers, proveedores de infraestructura y organizaciones nombradas en el material de prensa del propio RSL — 1.013 hosts unicos tras deduplicar. A cada uno le pedimos /robots.txt sobre HTTPS con verificacion de certificado activa, un request por host, y parseamos la directiva License:.

725 hosts devolvieron un robots.txt no-HTML con HTTP 200. De esos, cinco llevaban una directiva License::

# directivas License: en robots.txt, 1.013 dominios, 2026-08-22
medium.com          -> https://medium.com/license.xml
theguardian.com     -> https://theguardian.com/license.xml
guardian.co.uk      -> https://theguardian.com/license.xml   # mismo destino
rslstandard.org     -> https://rslcollective.org/royalty.xml
rslcollective.org   -> https://rslcollective.org/royalty.xml # mismo destino

Cinco directivas, tres URLs de licencia distintas, y dos de los cinco hosts son propiedades del propio RSL. Fuera de los sitios web del estandar, los mil dominios top de la web abierta mas cincuenta publishers nombrados arrojaron dos adoptantes: Medium y el Guardian.

El numero de control es mas interesante que el titular. En el mismo crawl, 21 hosts llevaban la directiva Content-Signal de Cloudflare — un mecanismo mas angosto, mas joven y no monetario que la propia especificacion de RSL cita como referencia normativa. Lo simple que sale por default en un proveedor de edge esta cuatro veces mas desplegado que el estandar con 1.500 organizaciones que lo endosan.

Como robots.txt es solo uno de cinco canales de discovery, revisamos los otros para las 50 organizaciones nombradas: un fetch directo de /license.xml, el header Link del homepage, y el HTML del homepage buscando <link rel="license" type="application/rsl+xml"> o un bloque RSL inline. Eso sumo exactamente un adoptante que robots.txt no habia visto: supertab.co, el proveedor nombrado en el material de prensa de RSL como el license server administrado. Otros dos hosts respondieron 200 en /license.xml — usatoday.com y forbes.com — pero ambos eran redirects 301 a paginas comunes, no documentos RSL.

Un hallazgo de ese barrido merece linea propia. El robots.txt de Medium anuncia una URL de licencia, y esa URL devuelve 403 detras de un challenge de bots de Cloudflare — tanto a nuestro user agent de auditoria como a uno de navegador. El documento que existe para decirle a los clientes automatizados que pueden hacer es ilegible para clientes automatizados.

Que dicen realmente las licencias vivas

Hay tres documentos RSL alcanzables en produccion. Los tres son suficientemente chicos para citarlos completos. Este es el del Guardian, de 336 bytes:

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="/">
    <license>
      <permits type="usage">ai-train ai-input</permits>
      <payment type="subscription">
        <custom>https://licensing.theguardian.com/</custom>
      </payment>
      <prohibits type="usage">all</prohibits>
    </license>
  </content>
</rsl>

Leelo como debe leerlo un cliente. El mismo elemento <license> permite ai-train ai-input y prohibe all. La seccion 4.9 de la especificacion resuelve terminos en conflicto con una sola regla: "los clientes MUST honrar la combinacion de derechos mas restrictiva". Un agente conforme aplicando esa regla a la licencia del Guardian concluye que todo esta prohibido, incluidos los dos usos explicitamente permitidos una linea mas arriba. La intencion humana es obvia — todo esta cerrado salvo que te suscribas — pero el documento tal como esta escrito no dice eso, y la regla que la spec provee resuelve en contra del publisher.

El documento del propio RSL Collective, de 301 bytes, permite ai-all con un <payment type="use"> que apunta a una URL <standard>. El de Supertab, de 514 bytes, permite search, prohibe ai-train y adjunta declaraciones <legal> de warranty y disclaimer.

Ahora el numero que importa. En los tres documentos vivos, la cuenta de elementos <amount> es cero. La cuenta de elementos <accepts> es cero. Ni una sola licencia RSL en produccion nombra un precio, una moneda o un protocolo de pago.

Todas degradan a un humano. El <custom> del Guardian apunta a una pagina de contacto de licenciamiento. El <standard> del Collective apunta a terminos de membresia. Para un agente autonomo que recibe un 402 y quiere pagar y seguir, la capa de licencias legible por maquina hoy resuelve a "anda a buscar una persona y negocia". Es exactamente el problema del walk-up que todo el renacimiento del 402 existe para eliminar.

Los license servers

La guia de RSL publica una List of License Servers. Tiene exactamente una entrada: la del RSL Collective, "servidor sin fines de lucro operado por publishers lideres de la web". El propio documento de licencia vivo del Collective nombra su servidor en el atributo server: https://api.rslcollective.org.

Ese hostname no resuelve. Lo consultamos contra dos resolvers publicos independientes y obtuvimos NXDOMAIN de ambos, mientras el dominio padre resuelve normalmente:

$ dig +short @1.1.1.1 api.rslcollective.org  # status: NXDOMAIN
$ dig +short @8.8.8.8 api.rslcollective.org  # status: NXDOMAIN
$ dig +short @1.1.1.1 rslcollective.org
172.67.175.231
104.21.64.35

El unico license server del directorio oficial, referenciado por el documento de licencia del propio organismo de estandarizacion y usado como ejemplo trabajado en su propia guia para desarrolladores, no tiene registro DNS. OLP no tiene un deployment de referencia que hayamos podido alcanzar.

La unica implementacion de OLP que si responde es la de Supertab, nombrada en el atributo server de su documento de licencia. La manejamos directo. POST /token con grant client_credentials y credenciales invalidas devuelve un rechazo limpio y con la forma de la spec:

# POST .../token  -> 401
{ "error": "invalid_client",
  "error_description": "Invalid client credentials" }

Eso es OLP funcionando como fue diseñado, y es la unica respuesta de ese tipo que obtuvimos en ningun lado. Pero POST /introspect en el mismo servidor devuelve 404 Not Found, asi que la validacion de tokens — el endpoint que un publisher necesita para chequear la licencia de un crawler — no esta implementada. Y supertab.co responde 200 sin header WWW-Authenticate, asi que CAP esta anunciado en el documento pero no aplicado en el recurso. Uno de tres endpoints de OLP, y ninguna enforcement.

Nada esta registrado en ningun lado

La seccion 10 de la especificacion se titula "IANA Considerations and Normative Changes to RFCs", y declara que "todas las acciones de IANA definidas en esta seccion son permanentes". Pide tres cosas: registrar el media type application/rsl+xml bajo RFC 6838, registrar un nuevo esquema de autenticacion HTTP llamado License bajo RFC 9110, y una extension normativa al RFC 9309 que agrega la directiva License a robots.txt.

Verificamos todo contra los registros vivos el 22 de agosto de 2026. El registro de media types de IANA en el arbol application tiene 1.795 entradas; rsl+xml no esta entre ellas. El registro de HTTP Authentication Schemes tiene 18 entradas — Basic, Bearer, Concealed, Digest, DPoP, GNAP, HOBA, Mutual, Negotiate, OAuth, PrivateToken, SCRAM-SHA-1, SCRAM-SHA-256, vapid y otras — y License no esta entre ellas. El RFC 9309 no fue actualizado.

Pedir no es registrar, y una especificacion no puede enmendar normativamente el RFC de otro con solo afirmar que lo hace. Es el mismo patron que documentamos en la auditoria de KYAPay, donde dieciocho claims JWT propuestos y diez valores de AMR tenian presencia cero en los registros correspondientes. Se esta volviendo la postura por default de la ola de estandares de agentes: publicar el vocabulario, describir el registro como hecho, saltear el proceso.

El artefacto de ingenieria cuenta la misma historia. El repositorio rslstandard/rsl es el unico repo publico de la organizacion. Creado el 2025-02-18, 46 stars, un fork, dos issues abiertas, ocho commits — todos del mismo autor, el chair del Technical Steering Committee — con el ultimo push el 2026-03-31 y un tamaño total de 11 KB. Su contenido entero es un README. No hay schema, ni suite de tests, ni validador, ni implementacion de referencia. Para un formato cuyas reglas de conformidad dependen de la precedencia entre elementos en conflicto, no hay nada contra que chequear un documento — que es exactamente como una licencia que permite y prohibe en la misma respiracion llega a produccion en un diario grande.

Que significa para LLM4Agents

La lectura honesta es que RSL es importante y todavia no es real. Las dos mitades importan.

Es importante porque es el unico intento serio de darle a un agente una respuesta legible por maquina a "que puedo hacer con esto", pegada al mismo 402 que responde "cuanto cuesta". Nuestro gateway ya esta del lado que paga en ese intercambio. Cuando un agente ruteado por nosotros baja una pagina, una API o una tool MCP, la respuesta puede llevar terminos que restringen que puede hacer despues el agente con esos bytes — pasarlos a un modelo como input, guardarlos en memoria, usarlos para entrenar. Son actos distintos con precios distintos, y ai-input contra ai-train es el primer vocabulario que los separa con claridad.

No es real todavia porque la mitad de pagos esta vacia. No hay ninguna licencia RSL viva que un agente pueda tarifar, ningun license server alcanzable en el directorio oficial, ningun media type registrado, y ninguna conciencia de RSL dentro de x402. Un agente que implemente RSL hoy obtiene una obligacion de compliance y ninguna capacidad de saldarla — puede enterarse de que el contenido esta restringido, y no puede pagar para desrestringirlo.

La amenaza es especifica y vale nombrarla. Si la capa de licencias madura con su precio expresado solo en ISO 4217 y su enforcement delegada a bot management, la capa de settlement sobre la que construimos queda diseñada fuera. El 402 se vuelve un aviso que rutea a un equipo de ventas, y el pay-per-crawl se vuelve un contrato enterprise con un login. Ese es el mundo en el que la identidad firmada de agentes importa mas que los rails de pago, porque el acceso se otorga por allowlist en vez de comprarse por request.

La oportunidad es la imagen espejada. RSL ya concedio el punto arquitectonico de que el pricing puede ser dinamico y delegado al protocolo de pago en runtime. Esa frase de la seccion 3.11 es una puerta abierta. El lado que provea payloads <accepts> que funcionen, montos reales y un facilitator que los settlee define que significa en la practica el campo de precio de la capa de licencias.

Como mantenerse en la frontera

Concreto, en orden.

1. Parsear RSL del lado comprador, ya. Cuando nuestro gateway o un agente que lo usa baja un recurso, chequear los cinco canales de discovery y adjuntar los terminos resultantes a la respuesta como metadata estructurada. Es un parser chico contra un vocabulario chico, y cuesta un request extra por origen con cache sobre max-age. El valor no es enforcement, es que los propios logs del agente registren que tenia permitido hacer en el momento en que leyo algo.

2. Implementar bien la regla de conflicto y loguear cuando muerde. La regla de lo mas restrictivo de la seccion 4.9 es un peligro real, y el documento del Guardian prueba que se dispara en produccion. Un agente que resuelva en silencio una licencia contradictoria a "todo prohibido" va a parecer roto para su operador. Mejor exponer la contradiccion explicitamente y reportarla aguas arriba — los publishers que producen estos documentos no tienen validador que la agarre.

3. Publicar un profile <accepts> que funcione para x402. El hueco aca es un documento que nadie escribio: como un payload x402 dentro de <accepts> mapea al array accepts de una respuesta 402 real, como <amount currency="USD"> se reconcilia con unidades atomicas de una stablecoin en una red CAIP-2, y que scheme aplica a que <payment type>. Per-crawl mapea a exact. Per-inference mapea a upto, el scheme medido que cubrimos en el deep dive de upto y Permit2. Escribir ese mapeo es una semana de trabajo y hoy no lo reclamo nadie.

4. Servir RSL en nuestros propios endpoints. Somos vendedores de recursos legibles por maquina, no solo compradores. Publicar un documento RSL sobre nuestros docs y APIs — con un <amount> real y un <accepts type="application/x402+json"> real — lo convertiria en la primera licencia viva del mundo que un agente puede efectivamente pagar. Es un cambio de un archivo con valor demostrativo desproporcionado.

5. Empujar ambos registros aguas arriba. application/x402+json tampoco esta registrado del lado de x402. Si la capa de licencias va a referenciar un media type de pagos como obligatorio, ese media type deberia existir en el registro de IANA, y el lugar natural para plantearlo son los working groups de la x402 Foundation antes que el organismo de licencias.

6. Seguir el camino de enforcement, no el conteo de endorsements. La metrica que predice si esto se vuelve infraestructura no es cuantas organizaciones firman una pagina de apoyo. Es cuantos origenes devuelven un 402 con un body application/rsl+xml o un header Link rel="license". Hoy ese numero es efectivamente cero. Vamos a re-correr este crawl de forma programada, y la primera vez que se mueva, la capa de licencias habra empezado a existir.

A los estandares se los juzga por lo que hay en el cable. Ahora mismo RSL tiene un buen vocabulario, un campo de precio vacio, un hostname de servidor muerto y un protocolo de pago que no sabe que existe. No es razon para ignorarlo. Es la descripcion de una costura sin terminar, y las costuras son donde esta el trabajo.