← All Articles

UCP Message Signing Merges: Cryptographic Trust Arrives

After weeks of refinement, Ilya Grigorik's comprehensive signature specification lands in the Universal Commerce Protocol — establishing cryptographic foundations for enterprise-grade agentic commerce.

Why This Matters

When AI agents start moving real money, trust becomes non-negotiable. How does a business know the request actually came from the agent that claims to have sent it? How does an agent verify the response wasn't tampered with in transit? These aren't theoretical concerns — they're blockers for enterprise adoption.

PR #156, merged February 17, 2026, answers these questions with a comprehensive cryptographic signing framework. The specification is substantial: 599 lines of new documentation in signatures.md alone, plus updates across the entire specification surface.

The Architecture

The signature framework establishes a layered architecture that works consistently across UCP's transport bindings:

Key Discovery via Profiles

One of the cleverer aspects of the design is how it reuses existing UCP infrastructure. Rather than creating a separate key discovery mechanism, signing keys are published in the same /.well-known/ucp profile that already handles capability negotiation. This means:

• The same fetch that enables capability negotiation also resolves signing keys
• Businesses publish keys at their profile URL
• Platforms (agents) publish keys that verifiers can discover via the UCP-Agent header
• No new infrastructure required — just new fields in existing structures

Transport-Specific Bindings

UCP supports both REST and MCP transports. Rather than forcing a single signing mechanism, the spec adapts to each transport's idioms:

REST uses RFC 9421 HTTP Message Signatures — the modern standard for signing HTTP requests. Covered components include @method, @path, @authority, content-digest, ucp-agent, and idempotency-key.

MCP uses detached JWS (RFC 7515 Appendix F), with the signature stored in meta.signature. The entire message is signed, excluding only the signature field itself.

What Changed Technically

The PR touched 12 files across the specification:

• New: docs/specification/signatures.md (599 lines) — the core signing specification
• Modified: overview.md — new Identity & Authentication section defining profile trust model
• Modified: order.md — webhook signing now uses RFC 9421
• Modified: checkout-rest.md, checkout-mcp.md — Message Signing sections
• Modified: rest.openapi.json — new signature headers in OpenAPI schema
• Modified: mcp.openrpc.json — signature field added to meta

Profile Trust Model

The specification introduces a two-tier trust model for profile discovery:

1. Pre-approved platforms: A registry of trusted agent platforms with cached identity (no network lookup needed)
2. Dynamic discovery: For unrecognized platforms, bounded by security constraints:
   • LRU cache to prevent repeated lookups
   • Global rate limits on discovery requests
   • Exponential backoff on failures
   • Async 503 + Retry-After for overload

Profile hosting requirements are strict: HTTPS-only, no redirects, Cache-Control with public and max-age >= 60s. Profiles are stable identity documents, not per-request configuration.

Evolution of the PR

The commit history shows how the specification evolved through working group discussion:

• Initial proposal: Custom Request-Signature and X-Detached-JWT headers
• First revision: Migrate to RFC 9421 for REST binding
• Second revision: Drop JCS canonicalization for request bodies; use raw bytes via Content-Digest (RFC 9530)
• Third revision: Support multiple auth mechanisms, not just signatures
• Fourth revision: Add @authority to signed components (cross-host replay prevention)
• Final revision: Define complete identity & key discovery protocol

Each iteration addressed real implementation concerns — this wasn't design by committee, but refinement through practical feedback.

Implications for the Ecosystem

For Agent Developers

Agents must now publish signing keys if they want to participate in signed transactions. The UCP-Agent header becomes even more critical — it's the identity anchor that verifiers use to discover your public keys.

For Businesses

The flexibility of auth mechanisms means businesses aren't forced into a single approach. Enterprise shops can continue using API keys or OAuth while adding signature verification. The spec explicitly supports this: "Implementations SHOULD maintain allowlists of trusted profiles."

For the Protocol

This closes the security gap that was blocking enterprise adoption. With cryptographic signing, UCP transactions become verifiable and tamper-evident — prerequisites for handling sensitive commerce operations.

What's Next

The signing spec establishes the cryptographic foundation, but implementation is the next hurdle. Expect to see:

• SDK updates across Python, TypeScript, and Go implementations
• Reference implementations of key discovery
• Profile registry bootstrapping for major agent platforms
• Interoperability testing as early adopters implement the spec