Resumen

  • La edición -04 de Agent Registry Protocol, presentada el 29 de septiembre como Internet-Draft individual, incorpora una estructura para comunicar el resultado de evaluar autoridad: decisión, motivos, momento, política y referencias condicionales a pruebas y vigencia.
  • El nuevo texto propone que el caché HTTP no prolongue una autorización más allá del límite material de frescura y que una brecha relevante en el flujo de eventos obligue a recuperar un estado autorizado o a responder sin afirmación. No es un RFC ni una norma avalada por la IETF.

Un registro podría seguir devolviendo el nombre correcto de un agente después de que se le retire una delegación. No habría un fallo de identificación; el error consistiría en reutilizar una respuesta favorable cuya base ya no es actual. Ese es el problema práctico al que Sankarshan Mukhopadhyay dedica la nueva sección 29 de su proyecto de protocolo ARPA. El documento está activo como presentación individual. La aspiración «Standards Track» que figura en la portada no demuestra adopción por un grupo de trabajo, aprobación de la IETF ni instalación del sistema en producción.

Conviene delimitar la novedad. La versión -03 ya decía que registrar, autenticar o anunciar capacidades no confiere por sí solo poder para ejecutar una acción. También contemplaba la frescura y los resultados indeterminados. La versión -04 baja esos principios a contratos más específicos para una respuesta y para quien la consume. En 29.1.7 aparece un objeto de resultado con decisión, códigos de razón, hora de evaluación e identidad, versión y aplicabilidad de la política elegida. Si hay permiso sujeto a condiciones, estas no pueden quedar implícitas. Si un dato derivado o histórico resulta material, se requiere una referencia al punto de control de la fuente. Cuando la frescura cambia la conclusión, debe constar o poder consultarse una política estable que la delimite.

No se trata de embellecer una ficha. La sección 29.3 cuenta únicamente allow y allow_with_conditions como respuestas afirmativas. Rechazo, incertidumbre y falta de aplicabilidad siguen siendo resultados distintos. La 29.4 impide transformar en activo, sin explicarlo, un estado restrictivo, contradictorio o desactualizado. Son requisitos propuestos por un autor dentro de un borrador, no reglas ya vigentes para cualquier servicio de agentes. Aun así, precisan la evidencia que faltaría si una aplicación se limitara a mostrar una luz verde sin política, fecha ni fuente.

El límite del caché ofrece un control verificable. En 29.7 no se prohíbe conservar respuestas HTTP: se exige que su tiempo de vida no rebase la vigencia o frescura material usada para evaluar autoridad. La identidad del agente puede durar más que la capacidad de afirmar que tiene permiso. Si no es posible establecer la actualidad de un estado decisivo, el proyecto pide una salida no afirmativa. Eso no describe un incidente real; la propuesta no aporta una encuesta de adopción ni prueba de un daño observado.

También importa qué ocurre si se pierde una actualización. Para un endpoint de eventos anunciado, 29.10 pide un identificador estable y una posición o checkpoint que permita detectar huecos. Si el hueco afecta al estado material, el consumidor no debería seguir afirmando permiso a partir del flujo incompleto: debe sincronizarse con una instantánea o punto de control autorizados, o abstenerse de afirmar. La recuperación es posible; no se prescribe una denegación irreversible. Otro apartado establece denegación por defecto para las escrituras y niega que el mero título de operador habilite la modificación de todos los registros de autoridad.

La matriz de conformidad propuesta exige identificar el papel implementado y asociar requisitos con pruebas positivas y hostiles. Un requisito para futuras pruebas no equivale a pruebas ya superadas. La noticia consiste en esta precisión temporal y operativa del borrador: la presencia de una entrada no puede prestar una vida indefinida a una decisión favorable.

Fuentes