Resumen

  • AAuth-R3 -00, presentado el 28 de septiembre de 2026 como Internet-Draft individual, propone ejecutar antes de la aprobación una llamada retenida cuando hacerlo no tiene efectos externos. No es una RFC, una decisión del IETF ni prueba de uso real.
  • Si la operación ya se ejecutó, la pantalla debe decirlo: la persona autoriza o rechaza que el agente reciba un resultado fijo. El recurso puede describir cuántos registros aparecieron y qué tipos de datos sensibles contienen.
  • Si la ejecución queda auditada, consume una cuota, se factura, afecta un límite de frecuencia o llama a un tercero, la aprobación debe precederla. «Solo lectura» es una descripción insuficiente.

Un permiso que llega después del cálculo

Una búsqueda de expedientes puede devolver más información de la que su frase sugiere. El recurso ejecuta una consulta, descubre salarios y domicilios en la respuesta y la mantiene fuera del alcance del agente. Ahora sí puede explicar a la persona el alcance concreto de lo que entregaría. Según la sección 10.4 del texto original de AAuth-R3, la aprobación en este caso es para liberar el resultado, no para iniciar la consulta que ya acabó. Presentarla como permiso para ejecutar haría creer al usuario que está controlando un hecho pasado.

La propuesta de una sola llamada puede incluir un elemento result opcional, reservado para cuando la operación ya corrió. Allí el recurso describe número de filas y categorías de campos; no envía la respuesta entera al servicio que presenta el consentimiento. El recurso decide qué información acerca del resultado comunica y qué parte finalmente entrega o redacta. Esta capacidad mejora la descripción de una decisión, pero también concentra responsabilidad: si omite un dato delicado, la persona no lo adivinará por la sintaxis de la petición.

La condición de entrada es estricta. Debe ser cierto que ejecutar no cambia nada fuera de la respuesta guardada. Una API de consulta puede dejar una marca de acceso sujeta a auditoría, gastar una unidad de cuota, generar un cobro o activar una llamada externa. Rechazar luego la divulgación no borra esos hechos. El borrador exige aprobación previa siempre que correr la operación sea en sí el evento con consecuencia. La pregunta operativa no es si el comando escribe en la base de datos, sino qué ocurre fuera del resultado cuando se pone en marcha.

Identificar la llamada aprobada

El registro de Datatracker mantiene la versión -00 como propuesta individual en estado I-D Exists. Su intención de seguir la vía Standards Track no equivale a una norma aprobada. El esquema liga una propuesta con operación y parámetros concretos a referencias r3_uri y r3_s256. En el recorrido HTTP 202 el recurso conserva la invocación. En el recorrido 401, el agente repite la llamada y el recurso debe comparar sus parámetros reales con los aprobados; los valores representados mediante un resumen deben conservar los mismos bytes. El token de una llamada no autoriza una segunda invocación.

Si el resultado ya está calculado en el caso permitido, no hay que imaginar qué responderá una consulta futura: la decisión de entrega cubre bytes existentes. Pero esa precisión técnica no decide por la persona qué datos deben salir. El recurso conserva el deber de describir y limitar la respuesta. El texto no ofrece mediciones de despliegues ni casos de incidentes. A diferencia de la cobertura anterior sobre presupuestos simultáneos de AAuth y entrega de eventos a agentes, aquí el riesgo está en confundir aprobación de divulgación con autorización retrospectiva de la ejecución.

Fuentes