Resumen

  • draft-vandemeent-ains-discovery-02 retira trust_score y min_trust del camino normativo: las réplicas conservan evidencia y postura de ruta, pero cada consumidor aplica su política local.
  • Firmas, secuencias y pruebas Merkle pueden demostrar custodia e integridad del historial. No demuestran por sí solas propiedad legítima del nombre, capacidad real, autorización ni conveniencia para una interacción concreta.

El debate sobre nombres de agentes suele comenzar por el sufijo y terminar demasiado pronto en una marca de “verificado”. AINS propone buscar un nombre lógico y recibir endpoint, capacidades, identidad referenciada, origen y material probatorio. Su segunda revisión es más interesante por lo que prohíbe: ya no permite que un número calculado en un registro viaje como verdad de protocolo.

El documento se publicó el 24 de septiembre de 2026 como Internet-Draft individual e informativo. No es RFC, no ha sido adoptado por un grupo de trabajo y no prueba que exista una red AINS desplegada. La noticia es una corrección conceptual dentro de una propuesta todavía abierta.

La corrección divide el antiguo concepto de confianza. Evidencia es un objeto verificable o su referencia. Postura de ruta es una observación de alcance, frescura, accesibilidad o papel del proveedor. Evaluación local es la interpretación que un consumidor hace bajo una política identificada. La admisión y el efecto vienen después y quedan fuera del protocolo de descubrimiento.

Esta separación evita que una observación cambie de naturaleza al cruzar un registro. Una respuesta de red no se convierte en identidad. El control de una cuenta no se convierte en mandato. Una firma no convierte una capacidad declarada en capacidad ejecutada. Una valoración favorable de un proveedor no se convierte en permiso universal.

La federación propuesta usa un historial de mutaciones firmado y append-only. Cada entrada lleva secuencia, fecha, operación, nombre, cambio, emisor y firma. Las réplicas comprueban la firma, rechazan secuencias no monotónicas y conservan el origen. Opcionalmente, una prueba Merkle muestra que la entrada pertenece al historial comprometido.

Eso responde preguntas de custodia: quién firmó, qué versión llegó, si fue reescrita y si dos observadores ven el mismo compromiso. No responde si el contenido era verdadero. RFC 9162 demuestra el valor y el límite de un log transparente: hace detectable la incoherencia, no legitima cada objeto incluido. RFC 9421 añade que una firma HTTP solo es útil después de decidir qué clave se acepta, qué componentes se cubren, qué antigüedad tolera la aplicación y cómo se evita el replay.

El caso de los nombres duplicados es una prueba excelente. AINS conserva el registro con el registered_at más antiguo, genera un evento de seguridad y no sobrescribe en silencio. La regla logra convergencia entre réplicas. Pero el primero también puede ser un ocupante oportunista. El orden temporal no resuelve el derecho al nombre; la reserva entre registros queda para trabajo futuro.

Por eso el operador debería almacenar la colisión, no solo el ganador. La interfaz debe explicar que el registro activo ganó por antigüedad, no por una investigación de propiedad. Si oculta el conflicto bajo una insignia verde, convierte una regla determinista en poder simbólico.

La verificación multicanal contiene otra ambigüedad instructiva. El borrador exige que el solicitante publique un nonce en al menos un canal externo. Probar una cuenta es útil, pero un canal no es múltiple y su control actual no prueba continuidad del sujeto. Dos o tres canales independientes pueden elevar la confianza de una política local; ninguno autoriza una operación futura por sí mismo.

La divergencia local es entonces una característica. Un hospital, una red social y un laboratorio pueden usar el mismo conjunto de evidencias y producir resultados distintos. Para que esa diferencia sea responsable, cada resultado debe revelar política, versión, entradas, frescura, alcance y motivo. “Confianza 82” oculta precisamente esos elementos.

También hay que someter a prueba las afirmaciones comparativas. El apéndice informativo dice que A2A no ofrece verificación criptográfica. La especificación A2A vigente permite Agent Cards firmadas con JWS, fija reglas de canonicalización y recomienda comprobar al menos una firma. AINS puede aportar una federación diferente, pero no puede tratar una tabla propia como inventario definitivo de lo que hacen otros protocolos.

Los campos internos del diseño pueden recuperar el poder eliminado. Los niveles core, verified, sandbox y reserved son etiquetas tentadoras. La procedencia del registro y las referencias a protocolos hermanos también pueden convertirse en jerarquías de facto. Una implementación fiel permitirá ignorar esas etiquetas, revalidar la evidencia y sustituir el evaluador sin dejar de resolver el nombre.

La privacidad es el coste menos reversible. Un registro público puede mostrar ubicación lógica, capacidades, rutas y referencias de historial. La replicación distribuye esa información fuera del control del origen. Un tombstone registra la retirada, pero no borra las copias exportadas. La política debe decidir antes de publicar qué se referencia, qué se copia, cuánto se conserva, cómo se descubren las réplicas y cuándo caduca un caché.

La regla de Lu Heng es especialmente aplicable: el registro conserva el registro; no controla la red. La capa común puede tener sintaxis, validación determinista, firma, portabilidad y conflictos visibles. La utilidad, el permiso comercial, la tolerancia al riesgo y la adopción se deciden localmente. Un asiento describe realidad observada; no crea autoridad por declaración.

El resultado operativo debería conservar seis recibos: respuesta exacta de descubrimiento, posición y frescura del log, verificaciones independientes, observación de ruta, política y veredicto local, y evidencia posterior de admisión, ejecución y resultado. La cadena permite discutir cada fallo sin fingir que todos son “falta de confianza”.

Fuentes