Resumen

  • AIP exige dos pruebas: verificar la firma con la clave presentada demuestra posesión; comparar esa clave con el registro del verificador o con el documento DID demuestra su vínculo con agentDid.
  • La revisión 03 asigna superficies de autoridad distintas a did:web, limitado al proveedor, y did:opena2a, de alcance ecosistémico. El tipo y el propósito autodeclarados no son permisos.

Una pasarela recibió una respuesta puntual, con nonce nuevo y firma Ed25519 válida. El sistema podía verificarla con la clave pública que viajaba en el propio mensaje. El dato ausente no era criptográfico: ninguna fuente independiente decía que esa clave perteneciera al agente nombrado.

Aceptar en ese punto habría convertido una prueba de posesión en una prueba de identidad. Cualquier actor puede generar un par de claves y firmar correctamente con él. La pregunta difícil no es si una clave firmó, sino quién tenía autoridad para asignar esa clave a agentDid.

Ese límite organiza la revisión 03 de OpenA2A Agent Identity Protocol (AIP), publicada el 2 de octubre de 2026 y con vencimiento el 3 de abril de 2027. Es un Internet-Draft individual, no un RFC, un documento de grupo de trabajo, consenso del IETF ni evidencia de despliegue. El texto aspira a Standards Track; la aspiración de los autores no equivale a estatus adquirido.

El sobre contiene más que la firma

El verificador crea un reto con 32 bytes aleatorios, el agentDid declarado, un nonce de 16 bytes, issuedAt, expiresAt e issuerDid. La ventana es de cinco minutos y los tiempos siguen RFC 3339 en UTC.

La cadena firmada es:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

La respuesta añade publicKey, keyId, signedAt y algorithm. Ninguno de esos cuatro campos forma parte de la cadena firmada. La clave adjunta sirve para comprobar que el remitente posee su correspondiente secreto, pero no puede certificarse a sí misma como clave autorizada.

Por eso el primer resultado debe conservar un nombre limitado: “firma válida bajo la clave presentada”. Si la interfaz lo resume como “agente autenticado”, oculta el origen de la atribución.

Posesión primero, pertenencia después

La primera regla de AIP comprueba la firma con la clave de la respuesta. La segunda compara esa clave con la vinculada a agentDid en el registro del verificador o en un documento DID resuelto. El borrador prohíbe confiar por sí sola en la publicKey embebida.

La frescura, el uso único del nonce y un issuerDid incluido en el conjunto de emisores confiables son barreras adicionales. No sustituyen la vinculación. Una respuesta fresca y no repetida firmada por una clave ajena sigue siendo una respuesta firmada por una clave ajena.

También conviene separar los componentes operativos. La verificación matemática puede funcionar mientras el resolvedor entrega un documento antiguo, no responde o ha sido alterado. Un DID correcto tampoco corrige una firma inválida. Guardar sólo un booleano borra qué control falló y qué autoridad respondió.

El método DID reparte poder

La revisión 03 reserva did:web para identidades circunscritas al proveedor. El proveedor sirve el documento DID, de modo que dominio, TLS, canal de publicación, caché y recuperación pasan a formar parte del sistema de identidad.

did:opena2a queda para identidades de alcance ecosistémico y su documento no lo sirve el proveedor de identidad. La forma anterior did:aip:aim_ es un alias desaconsejado. La verificación debe tratar el identificador como opaco y enviarlo al resolvedor adecuado, sin deducir confianza de un prefijo conocido.

La diferencia decide quién puede cambiar una vinculación. did:web hereda disponibilidad y recuperación del proveedor; la vía ecosistémica necesita otra gobernanza, actualización y resolución de disputas. Un fallback silencioso no mejora sólo la compatibilidad: transfiere autoridad de un dominio a otro.

El borrador señala que, a 8 de septiembre de 2026, el resolvedor de referencia respondía únicamente al alias antiguo. No prueba el estado actual de ningún servicio, pero muestra una tensión de migración: el método especificado y el método que entiende el código pueden no coincidir. La auditoría debe conservar cuál resolvió realmente.

Declarar una función no concede permiso

El type del agente es informativo y no debe decidir seguridad. El declaredPurpose opcional puede añadir contexto, pero su ausencia no permite rechazar al agente y su presencia no debe entrar en la autorización. “Agente de compras” o “asistente de análisis” sigue siendo una afirmación propia hasta que exista prueba independiente.

Incluso una clave bien vinculada sólo identifica. No dice si el agente podía gastar, configurar, firmar o actuar ahora. Identidad, capacidad declarada, autorización, ejecución y resultado externo requieren pruebas separadas. La realidad no cambia porque una respuesta JSON esté bien formada.