Resumen

  • El Datatracker del IETF mantiene la solicitud de BoF de AUDIT en estado Declined. La lista no-WG creada el 31 de agosto de 2026 abre un foro para revisar la propuesta, no un Working Group.
  • La respuesta del IESG no descartó el valor de auditar acciones de agentes: consideró demasiado amplio el alcance y pidió aclarar qué lagunas quedan tras OAuth, WIMSE, OpenTelemetry y otros trabajos.
  • La arquitectura individual propone registros de interacción, acción, delegación y transición de autorización, pero reconoce que no resuelve la negativa a registrar, la colusión total, el alineamiento del modelo ni todavía un modelo de amenazas detallado.
  • Para impedir que la actividad se disfrace de mandato, conviene publicar un recibo de estado que separe foro, BoF, carta constitutiva, adopción, revisión, RFC e implantación.

La dirección de correo no cambia el veredicto

La señal más reciente llegó el 31 de agosto, cuando la Secretaría del IETF anunció la lista AUDIT. La lista da a quienes impulsan AUDIT un sitio estable para rehacer el alcance y discutir una carta. No obstante, el objeto institucional anterior conserva su estado. La ficha de la solicitud de BoF, versión 02, la identifica como “Declined BOF request” y muestra “Declined”. El índice de solicitudes ofrece la misma lectura.

La última actualización de la ficha es del 6 de julio y el campo de liderazgo responsable está vacío. En el cuerpo aparecen los directores del Área de Seguridad como AD propuestos y Yaroslav Rosomakho como presidente propuesto. Son piezas de un diseño de gobernanza que no llegó a aprobarse, no cargos vigentes que puedan citarse sin el adjetivo.

La definición oficial de la lista evita cualquier duda. El directorio de listas no-WG dice que servirá para debatir un posible BoF AUDIT, actualizar una carta propuesta y avanzar hacia la formación de un nuevo WG. En la fecha de corte, el archivo de audit contiene únicamente el mensaje de creación. El futuro verbal del texto es una frontera de autoridad.

Las directrices de listas no-WG permiten precisamente que una lista tenga como intención formar un grupo. La solicitud recibe la aprobación del Area Director pertinente. Pero lo aprobado es el recurso de comunicación. Un BoF, una carta, unos hitos y unos responsables necesitan sus propias decisiones.

El RFC 2418 muestra lo que falta. Un grupo de trabajo se organiza alrededor de una carta acotada, con presidencia, supervisión de área y proceso definido. Entre sus atributos figura una lista de correo. La lógica no es reversible: que todo WG necesite una lista no convierte toda lista en WG. Una sala de deliberación puede producir legitimidad, pero no la trae incorporada.

Dos palabras para dos momentos

El intercambio de junio empleó otra palabra. En la réplica de los proponentes del 5 de junio se conserva el mensaje del IESG del día 3, que calificaba la petición de “deferred”. El razonamiento era matizado: auditar acciones de agentes se consideraba un buen concepto, pero la propuesta abarcaba demasiado. Hacía falta estrecharla, consultar a OAuth y WIMSE y justificar por qué el trabajo existente o un perfil de OpenTelemetry no solucionaban la necesidad. Algunas nociones de intención y política, añadía, quizá correspondieran mejor a un marco jurídico.

Los autores cuestionaron el procedimiento y la oportunidad del aplazamiento, defendieron el problema de reconstruir pruebas entre dominios administrativos y continuaron una conversación específica sobre el alcance. Nada de ello debe borrarse: explica tanto la objeción como la respuesta y puede orientar una futura propuesta.

Tampoco hace falta traducir “deferred” en una aprobación latente ni “Declined” en una prohibición perpetua. La primera palabra pertenece al mensaje de junio; la segunda, al estado actual del registro. Un recibo institucional guarda ambas con fecha, actor y fuente. Una solicitud nueva podrá crear otro estado cuando exista.

La distinción enlaza con una regla de gobernanza más amplia. El ensayo de Heng Lu sobre el espejismo multistakeholder critica el salto desde asistir o participar hasta representar a un principal. En AUDIT, poder escribir en una lista demuestra acceso a un foro. No demuestra que el IETF haya delegado autoridad normativa en los participantes.

Cuatro registros para un problema real

El borrador de arquitectura AUDIT, fechado el 18 de mayo, no es una cáscara institucional. Aborda una dificultad concreta: un agente recibe una instrucción, delega en otro actor, utiliza servicios sujetos a políticas distintas, solicita más permisos y provoca un efecto. Los registros locales pueden demostrar fragmentos, pero no la cadena conjunta de intención, autoridad, acción y cambio de autorización.

El documento propone cuatro clases. Los Interaction Records conservan solicitudes, respuestas y aprobaciones en la interfaz con la persona. Los Action Records representan lo que ocurrió en el límite de ejecución. Los Delegation Records describen qué autoridad fue cedida, con qué alcance y restricciones. Los Authorization Transition Records capturan la concesión inicial, la autorización reforzada, una reducción, una revocación o la expiración.

Un contexto de auditoría compartido relacionaría episodios y referencias previas. Cada actor emitiría su perspectiva, y un almacén parcialmente confiable podría normalizarla para un auditor. La atestación y la transparencia aportarían garantías opcionales. Esta taxonomía corrige una confusión frecuente: la correlación entre dos sucesos no basta para demostrar que el segundo estaba autorizado por el primero.

El propio borrador señala límites severos. No confía por defecto en el agente. No resuelve que un servicio se niegue a registrar su frontera. Tampoco la colusión de todos los papeles relevantes ni el alineamiento del modelo. El análisis profundo de amenazas queda para después. Una colección de registros válidos puede seguir siendo selectiva; la ausencia de una mentira no demuestra la presencia de toda la verdad.

Además, la materia prima del auditado es sensible. Los mensajes exponen intención, los registros de acción exponen operaciones y relaciones comerciales, y los identificadores globales pueden enlazar la vida de una persona entre empresas. Hasta un hash publicado revela que cierta interacción ocurrió en un instante. La completitud tiene un precio de vigilancia que no puede quedar fuera de la carta.

El borrador individual sobre conversaciones verificables de agentes podría alimentar la capa de interacción. Pero no es un documento adoptado por un WG AUDIT: ese grupo no existe. Firmar una conversación tampoco fija la minimización, la retención, la revelación selectiva ni su unión legítima con acciones posteriores.

Un inventario de piezas, no una apropiación de territorio

El pedido del IESG de estudiar trabajos adyacentes obliga a asignar correctamente cada propiedad.

El RFC 8693 de OAuth Token Exchange permite expresar delegación y cadenas de actores en intercambios de tokens. Es una prueba relevante sobre autoridad transmitida. No narra por sí solo la instrucción original, las transiciones posteriores, el resultado y el juicio de un auditor. El protocolo base deja fuera las semánticas detalladas, las propiedades de seguridad y los modelos de confianza de los tokens.

La recomendación W3C Trace Context propaga identificadores para correlacionar segmentos de una petición distribuida. Ayuda a saber que dos observaciones pertenecen a un flujo. No afirma que había permiso, que una delegación se limitó correctamente o que una persona aprobó una acción. La continuidad técnica no es legitimidad.

El RFC 9334, arquitectura RATS, organiza Evidence, Verifiers, Attestation Results y la decisión de política de un Relying Party. Puede informar sobre componentes y entornos. No establece autoridad legal ni fidelidad a la intención: un sistema genuino y sano puede ejecutar un mandato inválido.

El RFC 9943 sobre SCITT define declaraciones firmadas, servicios de transparencia append-only y recibos de registro o inclusión. Hace más detectable una supresión o alteración posterior. No prueba que el contenido sea verdadero, que no falte ningún evento o que el emisor tuviera permiso. Un recibo protege una afirmación como objeto; no resuelve su significado.

Un alcance creíble debe decir qué queda en OAuth, WIMSE, RATS, SCITT, HTTP y observabilidad, y qué unión interdominio no pertenece hoy a ninguno. El valor de AUDIT no se medirá por la cantidad de grupos enumerados, sino por la precisión con la que evita duplicarlos y se hace responsable de los huecos.

El IETF también necesita trazabilidad de autoridad

AUDIT plantea cómo conservar autoridad y acciones dentro de un sistema de agentes. Su recorrido ofrece una oportunidad para aplicar la misma higiene al proceso de estandarización. La pregunta institucional no es quién dejó mensajes o borradores, sino quién tenía competencia para cambiar el estado del trabajo.

Un recibo público empezaría con un identificador estable del problema y una versión concreta. Clasificaría el estado: propuesta, BoF aplazado o rechazado, conversación no-WG, BoF aprobado, carta en preparación, WG activo o concluido. Para cada transición conservaría actor competente, fecha, enlace y tenor exacto. La siguiente revisión mostraría el delta de alcance y los asuntos transferidos a grupos vecinos.

Los nombres de AD y chairs seguirían siendo propuestos hasta una designación. El foro sería un campo distinto de la autoridad. Una carta tendría versión y fecha de aprobación o valor nulo. Cada documento indicaría si es individual o adoptado, con su acto de adopción. WG Last Call, IETF Last Call, evaluación IESG y objeciones pendientes aparecerían como pasos diferentes.

La publicación tampoco sería un cajón único. Internet-Draft, corriente y categoría de RFC, implementación y política operativa describen realidades separadas. Un RFC no demuestra despliegue; un despliegue no convierte automáticamente una opción local en consenso; y un producto compatible con un draft no lo vuelve estándar.

El historial debe ser acumulativo. Si una solicitud revisada triunfa, enlaza el rechazo y explica qué se eliminó o reparó. Si un WG adopta un texto, no reescribe el estatus de sus versiones individuales. Así se preserva la procedencia del mandato en vez de presentar una línea sin fricciones hacia el éxito.

Aplicado hoy, el recibo diría: hay borradores individuales; hubo una solicitud de BoF versión 02; el IESG valoró el problema y pidió una reducción; el Datatracker registra Declined; existe una lista no-WG para explorar otro BoF y otra carta; no hay liderazgo responsable nombrado, carta aprobada, WG, adopción o consenso IETF.

Privacidad, omisiones y derecho a no enlazar

Una futura especificación tendría que minimizar datos por tipo de registro. Cuando el contenido no deba viajar, puede separarse y usar hashes o revelación selectiva. Entre organizaciones deberían preferirse identificadores opacos o por pares, salvo que exista una necesidad autorizada de correlación global. Poder unir registros no crea el derecho de hacerlo.

El auditor necesita su propia autorización y un propósito delimitado. Diagnóstico, contrato, investigación de seguridad y obligación regulatoria justifican retenciones diferentes. Los huecos, rechazos y pruebas inaccesibles deben aparecer como tales. Un sistema que rellena silencios produce un relato más legible y menos verdadero.

Por eso la lista recién creada es útil antes de que exista mandato. Permite convertir estas preguntas en límites de una carta: qué es protocolo, qué pertenece a un perfil de implantación, qué depende de política y qué no debe capturarse. Llamarla lista no menosprecia la tarea. Le da espacio para merecer un estado posterior.