Resumen

  • La primera versión individual de AAuth Events, fechada el 28 de septiembre de 2026, permite que un recurso envíe un evento firmado al proveedor de agentes (AP) cuando el agente no tiene un punto de entrada disponible.
  • El código HTTP 202 exige que el AP haya registrado de forma duradera el evento aceptado; no demuestra que el agente lo recibió, verificó o utilizó antes de que caducara el token.

Una oportunidad de reservar un turno dura minutos; el agente que debía evaluarla está desconectado. El recurso remite el aviso a un buzón permanente y recibe una respuesta satisfactoria. Horas después, el agente vuelve a conectarse y encuentra el mensaje intacto. Esa secuencia no describe un fallo observado de una plataforma AAuth, sino una prueba de diseño: un evento puede haberse conservado perfectamente y haber perdido, entretanto, su capacidad de autorizar una respuesta. La diferencia entre memoria y oportunidad es el núcleo del nuevo borrador.

Dick Hardt presentó AAuth Events como Internet-Draft individual -00 el 28 de septiembre de 2026. Su destino indicado es una posible Standards Track; en el momento de la revisión, el Datatracker de la IETF solo confirma que existe el borrador. No es una RFC aprobada, una adopción por un grupo de trabajo ni un resultado de despliegue. El texto amplía una propuesta AAuth anterior para agentes que actúan por una persona. Su problema concreto aparece después de la interacción ordinaria: un recurso necesita avisar de algo a un agente que quizá ya no está conectado o no acepta webhooks entrantes.

El agente se suscribe a eventos de un recurso. Cuando hay una novedad, el recurso prepara un token de evento firmado y un cuerpo, y los envía al AP del agente. Ese intermediario puede estar en línea cuando el agente no lo está. Antes de aceptar, el AP verifica la firma del recurso, la audiencia del token, la suscripción vigente y la correspondencia del cuerpo con la huella body_s256. El borrador admite detectar duplicados mediante el emisor y el identificador del evento. Son comprobaciones sobre la procedencia, el destinatario y la integridad en el primer salto. No son una constatación de lectura por parte del agente.

El 202 Accepted tiene una condición fuerte, pero limitada: el AP no debe emitirlo hasta haber guardado de manera duradera el evento aceptado para su entrega posterior. El recurso obtiene así una prueba útil de que su publicación no se evaporó en una cola provisional. Sin embargo, el tramo AP-agente queda fuera del alcance del borrador y depende de la plataforma. El texto no prescribe un método universal de notificación, un recibo del agente, un calendario de reintentos ni una garantía de entrega completa. Afirmar que el recurso «notificó al agente» basándose solo en el 202 adelanta una conclusión que la especificación no respalda.

La caducidad impide convertir cualquier entrega tardía en un éxito recuperado. El token del evento tiene un campo de expiración; cuando el agente recibe el material, debe comprobar la validez del token, la audiencia, la huella del cuerpo y el contexto local. No debe actuar si el token ya caducó o si el cuerpo no coincide. La retención duradera en el AP conserva evidencia de lo enviado, no amplía automáticamente el plazo para tomar una decisión. En el ejemplo de la reserva, el resultado correcto del agente reconectado puede ser no actuar.

Un panel que colorea de verde la notificación desde que el AP responde ocultaría precisamente esa pérdida de utilidad.

También hay que separar integridad y puntualidad. body_s256 puede revelar que el AP modificó o sustituyó el cuerpo recibido. El propio borrador advierte que esa huella no impide que el AP retenga o demore el evento. Un mensaje no alterado puede llegar demasiado tarde; un mensaje entregado a tiempo puede rechazarse por contexto o audiencia; y un mensaje validado no prueba que una acción se ejecutó. Son transiciones distintas. No hace falta atribuir mala fe a un proveedor para ver el problema: una interrupción, una cola mal dimensionada o una decisión de producto sobre cuándo despertar al agente pueden producir una demora con el mismo efecto práctico.

El buzón permanente compra disponibilidad a cambio de visibilidad. El AP ve a qué recursos se suscriben sus agentes y ve el contenido de los eventos. El borrador reconoce que esto difiere del objetivo del protocolo AAuth principal de no revelar al AP el uso de recursos de la persona. No implica que todas las plataformas exploten esa información ni que sea imposible minimizarla. Sí significa que la privacidad ya no puede presumirse heredada del diseño anterior. El operador debe decidir qué identidades y qué fragmentos del cuerpo son imprescindibles para el reenvío, y justificar lo demás.

La noticia, por tanto, no es simplemente que los agentes podrán recibir webhooks de otra forma. Es que la arquitectura formaliza un primer recibo sólido y deja el resultado decisivo en una segunda frontera de confianza. Quien evalúe el sistema debe pedir pruebas distintas para el depósito, la entrega, la verificación y la acción; además debe conocer el nuevo mapa de datos visibles por el AP. El borrador resuelve la regla del depósito, pero no autoriza a presentar el resto como una garantía ya especificada.

Fuentes