Summary

  • El borrador coloca flujos, servidores de autorización y superficies de invocación en /.well-known/agent-capabilities.
  • Una operación ausente de todos los flujos anunciados queda cerrada. El servidor de recursos no debe ejecutarla aunque figure en una instancia de autorización aprobada.

Se aprobó el permiso ayer. Hoy el agente llega y la operación ya no está en el escaparate. El borrador de descubrimiento y autorización resuelve el conflicto a favor de lo que el origen publica ahora: los flujos anunciados delimitan las operaciones abiertas, y el servidor de recursos debe negar las demás. Al servidor de autorización le pide que rechace una instancia que incluya una operación cerrada. No se trata de un cambio cosmético en una página de ayuda; el archivo participa en el límite de ejecución.

La misma comodidad crea un punto de mando. La sección 8.6 explica que un atacante con escritura sobre contenido estático del origen podría sustituir el documento y enviar a futuros agentes a superficies de invocación elegidas por él, o apartarlos de los flujos auténticos. El ejecutable de la aplicación podría no mostrar un solo cambio. Los autores proponen someter el documento al control de cambios de la versión de la aplicación. La RFC 8615 ya advertía que los administradores pueden pasar por alto rutas .well-known; esta propuesta pondría allí instrucciones que afectan el trabajo de un agente.

En aplicaciones nativas, una copia dentro del paquete permite descubrir capacidades sin conexión. El texto la trata como caché: antes de la primera operación remota de cada sesión, la aplicación debe consultar la copia de su origen asociado y usarla si difiere. Una operación borrada del origen no puede revivir porque permanezca en un paquete antiguo. La distribución de la aplicación y la apertura efectiva de operaciones tienen, así, controles distintos.

El nombre y el logotipo del servicio tampoco autentican al operador. El borrador exige atender al origen y al canal autenticado; si existe metadata OAuth de recurso protegido, las listas de servidores de autorización han de coincidir. El registro del IETF lo mantiene como borrador individual. Para probar un efecto operativo hacen falta el historial del archivo de una aplicación concreta y registros del servidor que muestren sus decisiones.