ACK v2: A Smaller Identity Core and an x402-Native Payment Profile

When we released the Agent Commerce Kit in May 2025, Claude Code was still in preview, agentic coding was still effectively autocomplete, and the project later known as OpenClaw had not launched. We designed ACK for the inevitable future where agents become full economic actors: paying and being paid for their work and interacting with each other.

Now agents are abundant in day-to-day work and are starting to perform real financial activity. Most activity is still agent-to-API commerce, but the economic surface is widening quickly.

Along the way, a few patterns from ACK have been validated by the market:

• Cryptographic request identity is emerging as a common pattern: Edge-ready verification schemes (Web Bot Auth, Trusted Agent Protocol) all build on signed HTTP requests.
• HTTP-based payments are emerging as a real pattern: x402 now operates under Linux Foundation governance, with AWS and Cloudflare shipping support, while Mastercard and Visa are using signed mandates, carts, and agent identity on card rails.

What changes in v2

ACK v1 leaned on W3C Verifiable Credentials for identity chains and permission grants. VCs are powerful and carry the right ideas: self-issued identifiers, portable signed claims, verification with no callbacks. But they also bring a steep learning curve: JSON-LD conformance, presentation exchange, and a resolver before you verify a single byte. In a world where the industry (and ACK itself) prefers JWTs, we started to wonder if the juice was worth the squeeze.

So in ACK-ID v2, we propose keeping the same ideas, but dropping the VC requirement. Grants are plain JOSE, while agents authenticate each request with standard HTTP message signatures that can be verified at the network edge.

const grant = await new SignJWT({
  scope: "invoices:read",
  cnf: { jkt: agentKeyThumbprint }
})
  .setProtectedHeader({
    alg: "EdDSA",
    typ: "grant+jwt",
    kid: ownerKeyThumbprint
  })
  .setIssuer("did:web:acme.com")
  .setSubject("did:web:acme.com:invoice-bot")
  .setAudience("https://api.examplebank.com")
  .setIssuedAt()
  .setExpirationTime("15m")
  .setJti(crypto.randomUUID())
  .sign(ownerPrivateKey)

An owner signs a grant and gives it to the agent. The agent signs each request with its own key and attaches the grant. The API verifies both signatures and checks scope. Who the agent is, what it may do, who said so: all in one request, equipped with a verifiable authorization trail.

Because grants use JOSE and requests use RFC 9421 HTTP Message Signatures, one identity layer now uses the same RFC 9421 primitives as Web Bot Auth, Trusted Agent Protocol, and whatever edge scheme ships next. Same on the money side: x402 works today, and the same offer/receipt pattern maps onto MPP, Mastercard Agent Pay, and other rails, on-chain and off. ACK-Pay stays as the pattern language on top: offers, receipts, and the trail from a payment back to the accountable owner. Interoperability at the core.

The RFC splits ACK-ID v2 into a small core plus 6 optional extensions. The core is implementable with a stock JOSE library and an HTTP client in an afternoon.

The split has two goals:

• Keep the core small enough to hold in your head.
• Make identity work reusable across protocols and rails.

ACK is an open protocol, and we want feedback on the direction. The RFC is open for review as a Pull Request on GitHub.

Agents are evolving from assistants into full economic actors. The identity layer for that has to say who the agent is, what it’s allowed to do, and who’s accountable, without breaking the auth standards already deployed. That’s ACK-ID.

Together, ACK-ID and ACK-Pay provide portable identity, bounded authority, and payment evidence. They are open protocols that anyone can use. Catena builds on them to enforce customer mandates through policy, manages approvals, and maintains an audit trail across rails.