Firmas de Mensajes HTTP (RFC 9421)

Qué son las Firmas de Mensajes HTTP

Las Firmas de Mensajes HTTP se definen en RFC 9421, un estándar de IETF para crear y verificar firmas digitales sobre partes de una solicitud o respuesta HTTP. Un cliente elige qué componentes cubrir (por ejemplo, el método, la URI de destino, la autoridad y encabezados seleccionados), construye a partir de ellos una base canónica de firma y la firma con una clave privada. El resultado viaja en dos encabezados: Signature-Input (Section 4.1), que enumera los componentes cubiertos y parámetros como created, expires, keyid y alg, y Signature (Section 4.2), que transporta el propio valor de la firma. Ambos usan la sintaxis de Structured Field Values de RFC 9651.

El receptor reconstruye la misma base de firma (Section 2.5) a partir de la solicitud que recibió realmente, busca la clave pública referenciada por keyid y comprueba la firma. Si algo cubierto por la firma cambió durante el tránsito, la verificación falla.

Por qué importan para apps, API y servidores MCP

La mayor parte del tráfico automatizado se identifica con una cadena user-agent o con un nombre de cliente elegido por sí mismo. Ambas son triviales de copiar. Una firma de mensaje es distinta: vincula una solicitud a una clave, y solo el titular de la clave privada puede producir una firma válida. Para una aplicación que recibe tráfico de rastreadores, asistentes y agentes autónomos, eso convierte "este cliente dice que es X" en "esta solicitud fue firmada por la clave que X publica".

Esa distinción es la base para tratar a clientes automatizados cooperativos como participantes conocidos en lugar de tráfico anónimo. Permite que una API enrute un rastreador firmado hacia un endpoint estructurado, aplique un límite de frecuencia distinto a un operador conocido o dé a un servidor MCP más contexto sobre quién está llamando a una herramienta.

Cómo funciona la verificación en la práctica

1. Analiza Signature-Input y Signature y confirma que estén cubiertos los componentes esperados. Una firma que no cubre nada útil demuestra poco.
2. Comprueba los parámetros created y expires para rechazar solicitudes obsoletas o repetidas dentro de tu tolerancia (consulta Section 7.2.2 sobre replay de firmas).
3. Resuelve keyid a una clave pública desde una fuente en la que confíes, como un directorio de claves que el operador publique en una ubicación conocida. El borrador del protocolo de IETF Web Bot Auth define un directorio de este tipo para clientes automatizados.
4. Reconstruye la base de firma exactamente como se especifica y verifícala con el algoritmo declarado.
5. Registra qué se verificó y en qué contexto, para que las decisiones posteriores puedan referenciarlo.

En producción, usa una implementación mantenida de RFC 9421 en lugar de analizar a mano: los detalles de canonicalización son fáciles de hacer mal. La guía sobre cómo verificar solicitudes firmadas de agentes de IA recorre cada paso con código.

Qué demuestra y qué no demuestra una firma válida

Una firma válida demuestra que la solicitud fue firmada por una clave y, si la clave se publica bajo un dominio, que la solicitud está asociada con el operador de ese dominio. No demuestra:

• que el operador sea honesto o que la acción sea segura,
• que una persona haya instruido o aprobado la solicitud (consulta autoridad delegada),
• que el cliente tenga permiso para hacer lo que está pidiendo (consulta autorización de agentes).

La evidencia de identidad y el permiso son preguntas separadas. La autenticación y la autorización propias de tu aplicación siguen decidiendo qué puede hacer un cliente. Nuestra entrada de blog sobre qué demuestran las solicitudes firmadas de agentes de IA, y qué no lo explica con más detalle.

Conceptos erróneos comunes

• "Firmado significa confiable." Firmado significa atribuible. La confianza es una decisión de política que tomas sobre la parte atribuida.
• "Las firmas reemplazan las claves de API." Responden a una pregunta distinta. Una clave de API dice qué cuenta está llamando; una firma dice qué cliente produjo la solicitud. Muchas implementaciones se benefician de ambas.
• "El tráfico sin firma es malicioso." La mayor parte del tráfico automatizado de hoy no tiene firma. La ausencia de firmas reduce lo que se puede establecer, nada más. Por eso Unknown es un resultado de primera clase.

Cómo trata Proof of Actor las firmas

En Proof of Actor, una firma que se valida contra una clave publicada se registra con la base Verified, acotada exactamente a lo que la comprobación estableció: la clave y el identificador al que pertenece. La clase resultante (normalmente Agent) nunca implica autorización. Los resultados fluyen hacia Understand para el análisis y hacia Route, donde tus propias políticas deciden si un cliente firmado obtiene una ruta estructurada, un límite diferente o ningún cambio en absoluto. Los estándares de agentes firmados como Web Bot Auth están evolucionando, y Proof of Actor está diseñado para verificar solicitudes firmadas a medida que maduran.

Lee más sobre qué puede establecer la evidencia, o solicita acceso anticipado.

Fuentes

• RFC 9421: HTTP Message Signatures: el estándar de IETF que define componentes de firma, parámetros y verificación
• RFC 9651: Structured Field Values for HTTP: la sintaxis de Signature-Input y Signature
• draft-ietf-webbotauth-httpsig-protocol: borrador de IETF Web Bot Auth que aplica RFC 9421 a clientes automatizados (trabajo en curso a noviembre de 2026)