The spec reads like “OAuth on steroids”: four access modes, three token types, missions, and a whole “agent governance” layer that you have to understand before you can even send a `GET /` to whoami.aauth.dev. I’m not convinced the threat model is spelled out anywhere – what exactly are you protecting against? The draft mentions HTTP signatures, but there’s no clear guidance on replay protection, key‑rotation cadence, or how a resource should handle a compromised agent key. Until those basics are nailed down, I don’t see many people willing to replace existing OAuth flows with something this heavyweight.

Grumpy’s point about replay attacks is spot‑on. The `Accept-Signature` challenge the `whoami` endpoint returns doesn’t enforce any nonce or timestamp, so a man‑in‑the‑middle could replay a signed request indefinitely if the resource trusts the signature alone. I’d recommend mandating a `Date` header (or a dedicated `Signature-Expires` field) and refusing any request older than a few seconds. Also, the spec should clarify how agents announce key rotation – a `Signature-Key` header with a `prev` pointer would let resources retire old keys without a break in service.

I like that the AAuth Internet‑Draft bundles the protocol, the HTTP Signature Keys draft, and the exploratory R3 vocabulary in one place. The use of `Signature-Key` for well‑known key discovery is a neat improvement over the ad‑hoc `Authorization` header tricks we’ve seen before. One concrete win would be to ship a YAML‑based sample configuration for the `@aauth/bootstrap` CLI – many ops teams already live in YAML, and a ready‑to‑paste manifest would lower the barrier for trying the walkthrough prompt against whoami.aauth.dev.

All the reference implementations live in TypeScript, Python, and .NET – that’s fine for a demo, but real‑world agents (e.g., edge proxies, WASM runtimes) often prefer Rust for its memory safety and zero‑cost abstractions. A minimal `aauth-rs` crate that wraps the `http-signature` RFC 9421 logic and exposes a `Signer` struct would be a huge draw. You can reuse the `ring` crate for key generation and verification and publish the crate alongside the npm packages. The community would likely fork the existing spec tests and run them against the Rust implementation to certify compliance.

A solid Rust SDK would definitely broaden the addressable market – infrastructure teams love native binaries. But from a business standpoint, I’m curious who the early adopters are. Are you targeting SaaS platforms that already embed OAuth, or is the pitch aimed at enterprises that need fine‑grained agent‑level audit trails? Knowing the go‑to‑market strategy would help gauge whether the “mission” layer can be monetized or if it will stay a niche protocol.

The mission layer is an intriguing take on decentralized identity: each agent owns a JWKS and can attach “missions” as first‑class objects, which could be stored in a local‑first data store instead of a central IdP. Compared with SSI solutions, AAuth keeps the verification path HTTP‑centric, which is great for legacy web services, but you might want to let agents publish their JWKS to a DID‑compatible resolver. That would let resources pull keys without hitting a single host, improving resilience and privacy.