The Identity Gap: SigV4, JWT, mTLS, and the Open-Source Race to Authenticate AI Agents – Part 2

    • In Part 1, we argued that AI agents break the identity model the web was built on, and that RFC 9421 is a natural — if incomplete — primitive for the layer that’s missing.

    That invites three fair questions:

    1. Doesn’t AWS Signature V4 already do this?
    2. Doesn’t JWT already do this?
    3. If 9421 is the answer, who’s actually building it?

    Honest short version: SigV4 and JWT are both excellent inside the trust domains they were designed for, and both struggle outside them. A healthy but still-early open-source ecosystem is converging on 9421 for the cross-domain agent case.

    Three existing tools, one missing shape
    Before we look at 9421 vs. any one of them, look at them side by side:

    AWS SigV4 JWT (Bearer) mTLS RFC 9421
    What’s signed Canonical request (fixed format) Claims blob only TLS handshake only Chosen request components
    Binds to request? Yes No — token is reusable Indirect (only the channel) Yes
    Key model Symmetric (HMAC) Asymmetric or symmetric Asymmetric (X.509) Asymmetric (or symmetric)
    Identity discovery IAM lookup iss + JWKS CA + SAN keyid → anything
    Survives proxies / logs? Yes Yes (but replayable) No Yes
    Multi-signer / delegation Via STS / AssumeRole Via delegated tokens No Native (multiple sig* labels)
    Replay protection 15-min server-enforced jti/exp (often missing) Session-scoped created/expires/nonce
    Designed for Inside one cloud Inside one issuer Inside one PKI Cross-domain

    Three honest observations:
    SigV4 is not a weak protocol. It provides genuine request integrity, scales to a planet’s worth of traffic, and AWS solved the delegation problem long ago via STS and AssumeRole — issuing short-lived symmetric creds bound to a role. What it isn’t designed for is cross-domain identity. The trust anchor is IAM; the moment you leave AWS, the model doesn’t travel.

    JWT is the one everyone reaches for, and it’s the one where the answer is most often “don’t.” A bearer JWT sitting in an Authorization header is, in practice, an agent-passing-a-credential-around pattern. If it leaks, it replays. It proves who you are to whoever asks, but it doesn’t bind to the specific request. Signed JWT-in-DPoP (RFC 9449) and various “sender-constrained token” extensions exist precisely because stock JWT doesn’t do what 9421 does natively. If you’re tempted to reach for JWT-per-request, you’re most of the way to 9421 already — you might as well use the standard designed for it.
    mTLS is the gold standard when you control both ends. Strong mutual authentication, zero request-level tax. It also requires certificate infrastructure, doesn’t survive TLS termination at a gateway, and can’t express “this specific request was authored by this specific key” in a form you can verify from a log six months later. mTLS and 9421 are complementary: mTLS authenticates the channel, 9421 authenticates the message.
    The one-sentence frame:
    SigV4, JWT, and mTLS are excellent inside a single trust domain. RFC 9421 is designed for cross-domain request authenticity — which is the shape the agentic web keeps producing.

    Where 9421 specifically closes gaps for agents

    1. Symmetric keys don’t compose across trust boundaries. AWS solves intra-domain delegation with STS — beautifully. But two unrelated agent frameworks can’t meaningfully “AssumeRole” into each other’s identity systems. 9421’s asymmetric model plus keyid indirection lets each party resolve keys through whatever trust store they already run.
    2. No hardcoded discovery. SigV4 hardcodes IAM; JWT hardcodes iss/JWKS. 9421 lets the keyid be a DID, a JWKS URL, a DNS TXT record (DKIM-style), a SPIFFE ID, an internal KMS handle. Portable by design.
    3. Algorithm flexibility. HMAC-SHA256 is fine today, but you can’t move a whole ecosystem to Ed25519 or post-quantum signatures without a new protocol if the algorithm is baked in. 9421’s alg parameter was designed to be swapped (with the usual caveat that verifiers should enforce a fixed algorithm rather than trust the self-declaration — see Part 3).
    4. Native multi-signature. Multiple Signature / Signature-Input pairs can coexist on a single request, keyed by label (sig1, sig2, …). That’s the mechanism behind a chain-of-custody signature across delegating agents.

    Who’s actually building this

    Good news: a lot of people, quickly. Honest caveat: this is an early-stage but rapidly emerging ecosystem. Several of the projects below are months old, some are pre-1.0, adoption numbers are small. Don’t read this list as “the space is mature.” Read it as “the space is converging on a shape, fast.”
    Agent-identity focused

    • Vestauth — from the creator of dotenv/dotenvx. Explicitly framed as “auth for agents.” Ed25519 + RFC 9421 + Web Bot Auth draft. One-line verification: vestauth.tool.verify(method, url, headers). Ships a CLI so agents can shell out: vestauth agent curl https://api.example.com/endpoint.
    • OpenBotAuth — open-source implementation of the IETF Web Bot Auth drafts. Node + Python middleware, a JWKS registry service, and agent-management tooling. More infra-heavy than Vestauth; closer to a platform.
    • AgentSign — zero-trust-style “agent passports.” RFC 9421 signatures layered with trust scoring and a vetting pipeline. Aimed at MCP tool-calling scenarios where you want provenance and policy.
    • Cloudflare Web Bot Auth — not a library, but Cloudflare verifies RFC 9421 signatures at their edge today to distinguish legitimate bots from scrapers. Production proof that this scales.
    • ApertoID-Signature — IETF draft that publishes agent public keys in DNS, DKIM-style. Still a draft; the design is sharp.

    General-purpose RFC 9421 libraries

    Projects pyauth/http-message-signatures Apache 2.0, active
    Go remitly-oss/httpsig-go MIT, full spec minus JWS
    Go dadrus/httpsig
    PHP macgirvin/HTTP-Message-Signer Full Structured Fields + all algs
    C curl + wolfSSL (in review) Native –httpsig-* CLI flags, Ed25519 + HMAC-SHA256

    Adjacent prior art worth knowing

    • Mastodon / ActivityPub — uses the older Cavage draft, not RFC 9421, but it’s the largest production deployment of HTTP signatures on the open web.
    • Sigstore / cosign — signs artifacts, not HTTP requests, but same conceptual family.
    • SPIFFE / SPIRE — workload identity. Complementary: a 9421 keyid can resolve to a SPIFFE ID.

    Where the gap still is

    Every project above either targets a single language runtime (Python, Go, Node, PHP), or is a higher-level platform (Vestauth, OpenBotAuth, AgentSign, Cloudflare). What’s missing is the layer beneath all of them: the HTTP client that every CI script, every shell-out, every embedded agent on a constrained device ends up using. That’s libcurl.
    This isn’t a claim that libcurl carries “most” HTTP traffic — Go/Node/Python native clients certainly dominate application traffic. The narrower, defensible claim is: a large share of CLI, CI, shell-out, and embedded traffic bottoms out at libcurl, and until signing lives there, a Python agent that delegates to a Go tool-server that invokes a shell script loses the chain of custody at the language boundary.
    That’s the gap the in-flight curl PR (#21239) is closing, with wolfssl-examples#566 providing a parallel reference C implementation on wolfCrypt. Part 3 opens the hood on both.

    Takeaways

    • AWS-only? Stay on SigV4. Don’t churn.
    • Cross-service inside one issuer with human users? OAuth/JWT is still fine. Consider DPoP / sender-constrained tokens if agents enter the picture.
    • Mutual service-to-service you fully control? mTLS, possibly with 9421 on top for per-request attribution.
    • Agents, MCP tools, cross-domain, or anything where a log needs to stay verifiable? RFC 9421.

    In Part 3, we open the hood, and get honest about the harder half, which is verification.

     
    If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

    Download wolfSSL Now