Skip to main content
L1 cryptographically verifies that the request came from who the headers claim it did, and that the body wasn’t modified in transit. RFC 9421 HTTP message signatures with replay-window enforcement and key rotation. Symmetric on both sides — agents verify inbound and sign outbound webhooks; callers sign outbound and verify inbound webhooks.

​
What an SDK at L1 must provide

If you’re picking an SDK or porting one to a new language, this is the L1 build target:
  • RFC 9421 message-signature signing for outbound requests.
  • RFC 9421 verification for inbound requests, including replay-window enforcement on created / expires and keyid-based key lookup.
  • A pluggable signing-provider abstraction — in-process keys for development, KMS / HSM providers for production.
  • Test fixtures or a verifier-test harness so adopters can assert their signing wiring is correct without booting a full agent.
For the cumulative cross-layer story (what L0+L1 buys you), see the SDK stack reference.

​
Pages in this layer

  • Security implementation profile — RFC 9421 wire details, KMS integration, replay-window tuning.
  • Production security profile — the optional adcp-prod-security-3.3 profile: signing, revocation freshness, and acts-for checks an endpoint commits to enforce.
  • Portable attestations — reference-first claim credentials, evaluator allowlists, safe resolution, verification outcomes, and action binding.
  • Webhook verifier tuning — clock-skew handling, key-rotation transitions, signature failure diagnostics.
  • Web Bot Auth request-signing profile — experimental in 3.3, adopted by DR-0023: one key-resolution rule from the covered Signature-Agent header, identity as an origin, mandatory nonce checks, one signature per request, and status-code error responses.