Composition & Canonical Payload Binding
Two companion IETF drafts sit underneath the Agent Action Capsule. One defines how independently-verifiable profiles compose into a single accountable record. The other defines the binding mechanism that makes that composition possible without drift. This page covers both, the open registry they share, and the conformance bar every entry has to clear.
Two drafts, one seam
Agent Accountability: Composition and Conformance (draft-mih-sato-agent-accountability-composition-00) is the framework. It defines a set of interchangeable question-slots — CAN (was the action permitted?), WHO (which accountable human authorized it?), WHAT (what did the agent actually do?), AUDIT (did the runtime enforce correctly?) — and specifies how independently-verifiable profiles answering each question compose into one record, plus a shared conformance-vector suite for testing that composition. It complements existing audit-architecture and record-format work rather than replacing it.
Canonical Payload Binding (CPB, draft-mih-sokolov-scitt-payload-binding-01) is the mechanism. It defines the shared construction — canonicalization, identifier derivation, and typed reference — that any payload profile declares once and inherits everywhere, so profiles can compose across implementations without a custom adapter per pair. The Agent Action Capsule is CPB's first registered payload profile.
Put together: composition says which questions a record needs to answer and how the answers join up; CPB says how the join itself is computed, byte for byte, so any two independent implementations land on the same digest.
How records compose: a shared action digest
Profiles compose by reference to a shared subject digest over the action — subject_digest = SHA-256(JCS(action)) — the join key every slot refers to. Digest equality is a join key, not proof of truth, authorization, or sufficiency on its own: native profile verification, digest recomputation, and receipt verification remain separate results that a conforming verifier must never collapse into one opaque boolean.
| Slot | Answers | First-instance profile |
|---|---|---|
| CAN — Authorization | was the agent permitted to act? | e.g. OAuth/AAuth, GNAP, policy engines |
| WHO — Named-human authorization | which accountable human (or quorum) authorized this exact action, before it ran? | a device-bound authorization receipt, offline-verifiable against the signer's key |
| WHAT — Agent Action Capsule | what did the agent actually do? (verdict-complete, byte-stable) | the Agent Action Capsule profile |
| AUDIT — Runtime gate | did the runtime enforce correctly, in causal order, tamper-evidently? | a policy gateway or observability log |
Any conforming profile may fill a slot; the set is open by design — belief-provenance is a named extension socket. Each slot may root in a different trust anchor, and the composition holds even if any one party is compromised or under review: no slot is a required root of trust for another.
The binding mechanism: CPB
| Move | What it does |
|---|---|
Canonicalize — jcs-n | RFC 8785 JCS over the normalized value (null, empty-array, empty-object members removed bottom-up), SHA-256, lowercase hex. One algorithm any independent implementation can run to recompute the same digest. |
| Derive identifier | A content-addressed identifier derived from the canonical form, over a declared exclusion set (fields like capsule_id or chain that can't be self-referential). |
| Typed reference | External evidence — an authorization grant, a policy decision, an upstream receipt — binds by its typed digest reference. The referenced data stays where it lives; only the commitment travels, and a verifier checks representation, exclusion-set context, and digest together, not the hex string alone. |
A payload profile declares its canonicalization algorithm and exclusion set once, in the Artifact Type Registry, and inherits derived-identifier and typed-reference semantics without restating the mechanics itself.
The open registry
CPB keeps one registry home for the whole profile family: a Payload Canonicalization Algorithm Registry and an Artifact Type Registry, both interim records pending IANA registration on RFC publication. The Agent Action Capsule is the first registered payload profile (agent-action-capsule, status Registered). MachineMandate is registering as the second — an owner-authored entry, pending the owner's confirmation of its digest-context fields.
Entries are owner-authored wherever possible, and the registration path is a three-rung ladder by provenance:
| Rung | Status | What it means |
|---|---|---|
| 1 — Owner-authored | owner-confirmed | the profile's own author or owner supplies every field and opens the PR. Highest provenance; the preferred path. |
| 2 — Third-party-documented | third-party-documented | someone other than the owner registers publicly pinned artifacts (exact spec revision + commit), names themselves as registrant, and makes no endorsement claim on the owner's behalf. Upgrades to owner-confirmed on any owner acknowledgment. |
| 3 — Provisional | provisional | a reference resolves, but the vector set is incomplete or the specification isn't pinned precisely enough yet. |
Entries are immutable once merged — a behavior change registers as a new entry rather than editing history — and CPB editors never fill in an owner's digest-context fields on their behalf.
Conformance rigor: mutants, not a rubber stamp
Registering a profile isn't a form submission. Every fired conformance-check category has to survive a mutation-probe self-test: for each category, the suite auto-generates a condition-removed mutant — the input with the very defect the check exists to catch — and asserts the checker actually flips to failure on it. A check that stays green against its own mutant is reported assertion-free and fails CI. A required conformance vector set must also be two-sided: positive vectors with pinned expected values, and negative (MUST-FAIL) vectors — negatives-only can't catch an implementation that's too strict, and positives-only can't catch one that accepts malformed input.
This is what makes registration a real bar rather than a checkbox: the suite doesn't just confirm a passing implementation looks right, it confirms the checks themselves would have caught the implementation being wrong.
Implementation status
The CPB conformance-vector suite is the acceptance gate. The Python reference implementation passes the full current suite, CI-verified across both positive and MUST-FAIL vectors. A second independent implementation, in TypeScript, is in progress — it currently passes an earlier vector snapshot and is being brought current with the full suite.
Read the source
- CPB spec: draft-mih-sokolov-scitt-payload-binding-01 ↗
- Composition spec: draft-mih-sato-agent-accountability-composition-00 ↗
- Registries of record: REGISTRY.md ↗
- Conformance vectors: scitt-payload-binding/vectors ↗
- Reference implementation (Python): scitt-payload-binding ↗
- Agent Action Capsule — the first registered profile: agent-action-capsule ↗