]> Action State Group, Inc.

spec@actionstate.ai

Security agent attestation bilateral cross-organization SCITT transparency refusal When an agent operated by one organization requests a consequential action from an agent operated by another, today's record of that exchange — if one exists — is kept by one side, editable by that side, and deniable by the other. Disputes reduce to my-log-versus-your-log. This document describes a bilateral attestation exchange for such actions: the requesting organization signs a request attestation binding it to the action and its material terms; the performing organization evaluates the request against deterministic constraints at the boundary where the action takes effect and signs an action attestation recording the constraint results and the disposition — performed, declined, or escalated to a human — by reference to the request; and each party acknowledges the other's attestation. The combined record binds each organization to its part, gives each proof of the other's, and can be registered with a Transparency Service so that a third party who trusts neither organization can verify the record end-to-end. The exchange records refusals with the same fidelity as performance, and degrades gracefully when a counterparty cannot attest, marking the record's reduced assurance rather than blocking the transaction.

Introduction Agents increasingly transact with agents of other organizations with no human present at the moment of delegation. The transports are standardized — RPC conventions, tool-call protocols, message queues — but transports answer how agents communicate, not who is accountable for what was requested and what was done. Each side keeps its own log, written by an interested party, alterable by that party, and carrying no assent from the other. When the payment posts twice, when the deletion was out of scope, when the delivery never happened, the evidence is two self-interested logs that need not agree. Classical signed B2B messaging — AS2/EDIINT signed MDNs, AS4/ebMS3 signed receipts with non-repudiation-of-receipt — binds parties to transmissions: it attests that a message was sent and received, not what an agent then did about it. Such schemes do not gate execution on verifying the requester's organizational identity at the boundary where the action takes effect, do not bind constraint evaluation into the performer's record, and do not record a disposition distinguishing an executed action from a refusal from a human escalation at the moment of action. The distinction this document draws is action-level, not transport-level. This document describes an exchange producing a bilaterally attested action record: each organization's signature over its part of the exchange is durable, independently verifiable evidence that it produced that part, each holds proof of the other's, and the combined record can be registered with a Transparency Service so third parties can verify it. It is an individual submission. It composes with the existing agent action record layer rather than defining a new one, and its records are designed to be consumable by the layers above the record, such as accountability composition . What any consumer derives from these records is that consumer's concern; this document defines the record, not what may be concluded from a collection of them.

Motivating Scenarios Cross-organization procurement. Org A's purchasing agent requests a fulfillment action from org B's agent. A's request attestation binds A to the order's material terms; B's action attestation binds B to what it did about them. A later assertion of different terms by either party can be checked against a record both parties signed, rather than argued over two private ones. Agent-to-agent service delegation. An orchestrating agent subcontracts a task across a trust boundary. Each hop produces its own bilateral record, so a failure in a multi-hop chain is attributable to the hop where it occurred rather than to the chain as a whole. Chain-linking semantics that make the full responsibility path independently reconstructable are left to a future revision. Refusal at the boundary. B's agent declines A's request as out of policy. B's action attestation records the decline and its constraint basis; A's acknowledgment is verifiable evidence contradicting a later claim by A that the request was never answered. The refusal becomes durable, third-party-verifiable evidence — for B, that its gate worked; for A, that the request was made and declined (see ). Shared history as a side effect. Every completed handshake yields a counterparty-attested record — evidence neither party can revise alone. Two organizations that transact accumulate a verifiable shared history without doing anything beyond transacting, and either can produce it later without asking the other's permission.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Requesting party:

The organization (via its agent) requesting a consequential action across an organizational boundary.

Performing party:

The organization (via its agent) that evaluates and disposes of the requested action.

Request attestation:

A signed statement by the requesting party describing the requested action and its material terms, bound to the requesting party's verifiable organizational identity and naming the intended performing party; including at minimum a content digest of the request, a nonce, a timestamp, and a validity window. A request attestation is valid only against the performing party it names, and only within its validity window (with an implementation-defined clock-skew tolerance the verifier applies).

Action attestation:

A signed statement by the performing party, referencing a request attestation by digest, recording the deterministic constraint results evaluated at the effect boundary — each constraint identified by reference so a third party can tell which check produced which result, pinned to a digest of the constraint-set snapshot in effect and carrying a result for every constraint in that set () — and the disposition of the request, bound to the performing party's verifiable organizational identity.

Acknowledgment:

A signed statement by which a party records receipt of the counterparty's attestation, completing the bilateral record. Receipt does not assert agreement with the attestation's contents; a party disputing a disposition does so in a subsequent linked record.

Party identifier:

An opaque string naming a party (requesting or performing) within an attestation. A party identifier MAY resolve to a registration entry admitted on the same Transparency Service (for example, one admitted under ), in which case the party is a registered principal with an admission record rather than a bare key. Where it does, the attestation carries the digest of the admitted Signed Statement as the reference.

Verifiable organizational identity:

An organizational identity a relying party can validate independently of that organization's infrastructure — a credential chaining to a root of trust the relying party accepts (a certificate authority, federation operator, registry, or published trust list). This document does not nominate roots.

Reduced-assurance indicator:

A marker recording that a given exchange completed with fewer than the full set of attestations (see ).

The Bilateral Exchange The exchange has four moves:

1. Request attestation. Before the performing party acts, the requesting party produces a request attestation over the action and its material terms. The requester is now bound: it cannot later deny having asked, or having asked on these terms.
2. Constraint evaluation. The performing party verifies the requester's organizational identity and evaluates the request against deterministic constraints at the boundary where the action would take effect — not at the transport edge. Verification gates execution: no verified request attestation, no consequential action (policy MAY permit degraded operation; see ).
3. Action attestation. The performing party produces an action attestation referencing the request attestation by digest and recording the constraint results and the disposition. Dispositions use the verdict_class vocabulary of ; that document is normative for the complete value set (e.g., executed, denied), so the record covers every outcome, not only success. A performing party MUST produce at most one action attestation per request attestation; repeated execution of a single request is representable only as distinct request instances, each with its own request attestation.
4. Acknowledgment. Each party acknowledges the other's attestation. On completion, each organization is bound to its part and holds proof of the other's.

Attestations and acknowledgments SHOULD be registered with a Transparency Service per — carried, for example, as the payload of a profiled Signed Statement per — so that inclusion and non-equivocation are verifiable by a party who trusts neither organization. A bilateral record that is not registered still binds the two parties to each other; registration is what makes it evidence for everyone else. Wire encodings for the four objects are TBD for a future revision; this document fixes the exchange, the binding obligations, and the disposition semantics. A future revision fixing wire encodings MUST require each attested object to declare the canonicalization under which its digest was computed, by identifier, within the bytes the signature covers — and MUST require a verifier to apply the declared construction and never to infer one from the object's shape. The expected identifier names RFC 8785 JCS ; what this document fixes is that the construction is named rather than assumed (see ). The hash function is part of the named construction, so agility is obtained by naming a different one, never by reinterpreting an existing name.

Constraint Records The evidentiary value of an action attestation rests on which deterministic checks were applied and what each returned. Three obligations make that record complete and tamper-evident. Constraint-set pinning. The action attestation MUST bind a content digest of the constraint-set snapshot in effect at evaluation time, alongside the per-constraint results. The digest fixes which constraints — their identities and parameters — were in force when the request was disposed, so that a verifier can establish the applicable constraint set as of the attestation's registration time, not merely at verification time — the same establishable-as-of-registration-time property that requires of key validity. A constraint set that can be silently re-parameterized after the fact would let a performing party restate what it was obligated to check; pinning its digest removes that degree of freedom. Input-commitment digest. For each evaluation, the performing party SHOULD bind an input-commitment digest — a digest over the inputs the constraints consulted — carried as a commitment and disclosable to the counterparty or an auditor under the selective-disclosure model (). This is a SHOULD, not a MUST: the state a constraint consults varies across deployments, and an honest SHOULD serves a verifier better than a nominal MUST that implementations cannot uniformly satisfy. A future revision MAY promote it on implementation experience. Completeness. The action attestation MUST carry a result for every constraint in the pinned set — each pass, fail, or not-evaluated (with a reason) — so that a constraint present in the pinned set but absent from the results is a verifiable omission rather than a silent gap. Selective reporting of only the favorable results is thereby detectable by any party holding the pinned constraint-set digest.

Refusal Across the Boundary A declined request is not a failed exchange; it is a completed exchange with a decline disposition. The action attestation records that the request was declined and on what constraint basis; the requester's acknowledgment completes the record. This has two consequences. For the performing party, a bilaterally-acknowledged decline is evidence, verifiable by an auditor who trusts neither party, that its boundary enforcement works. A refusal is the strongest form of this evidence, because here even the counterparty that was refused has signed the record. For the requesting party, a history of acknowledged declines is legible too: a pattern of out-of-policy requests is now provable by its counterparties. Bilateral records cut both ways by construction; parties should expect their requesting behavior, not only their performing behavior, to be establishable by someone else.

Graceful Degradation Counterparties will be of mixed capability for years. A performing party whose counterpart cannot produce request attestations MAY proceed under policy, producing its own action attestation unilaterally and recording a reduced-assurance indicator in place of the missing attestations. The record format is the same; the assurance marking differs. This keeps one protocol across mixed peers while preserving the distinction relying parties need: a fully-bilateral record and a degraded record are never confusable, and a consumer can require a minimum assurance level before treating a record as input. Degradation MUST be recorded, never silent.

Dispositions Across the Asymmetry The action dispositions above record what the performing party decided about the action. A second, smaller class records what happened to the exchange when it does not complete symmetrically; this class is meaningful only because the record is bilateral. Three asymmetry dispositions are defined, entered through the schema-extension protocol of and kept distinct from the action vocabulary:

• delivery_unconfirmed: the requesting party emitted its attestation but delivery to the performing party could not be confirmed — the weakest outcome, as the counterparty may never have received the request.
• counterparty_timeout: delivery was confirmed, but the performing party did not countersign within the request's validity window; the request lapses into this disposition when the window closes.
• countersign_refused: the performing party was reached and explicitly refused to countersign.

In this document, to countersign means that the performing party issues its own signed half citing the request. It is not a COSE countersignature and not a Transparency Service function; in SCITT terms each half is a separate Signed Statement from a separate Issuer. These are weaker than, and MUST NOT be conflated with, a declined action (): a decline is a performed boundary decision that the requester acknowledges — strong evidence — whereas a refusal to countersign is a failure of the exchange, not a decision about the action. For the same reason, a party that declines to engage before any request obligates it is not a party that fails to countersign a request already made; only the latter is evidentiary against the performing party. An asymmetry disposition binds to its request by correlation identifier and the shared action digest; a half that cannot be matched to a counterpart is an orphan — a defined state, not an error. A requesting party's half, registered with a Transparency Service () and marked with an asymmetry disposition, is admissible evidence that the attempt was made — the one fact neither party can establish alone — and a verifier weights a registered-but-unacknowledged record accordingly.

Delivery Intermediary The exchange completes agent-to-agent; no intermediary is required, and the integrity of the record never depends on one. Where the parties are not simultaneously reachable, a delivery intermediary MAY store and forward the attestations and issue delivery receipts. The delivery intermediary is an optional, substitutable role: anyone can run one, delivery intermediaries federate, and the role reads no payloads — attestations traverse it as opaque, integrity-protected blobs, so a delivery intermediary learns that a record moved, not what it said. A delivery receipt is itself an accountability claim, so a conformant delivery intermediary MUST register the digests of the receipts it issues with a Transparency Service it advertises in discoverable metadata, so that Relying Parties and Auditors can check its Receipts for consistency, and may register them with more than one Transparency Service so that no single operator is relied on alone; the Transparency Service is the delivery intermediary's choice, this document names none, and a delivery intermediary that will not register its own receipts is non-conformant. A receiving gate SHOULD issue its own signed acknowledgment citing the envelope receipt by digest, so that delivery becomes a fact both parties assert rather than one the delivery intermediary asserts alone. Signed delivery receipts, and the fabrication attacks against them, are long-settled ground — the email DSN and MDN mechanisms (, ) addressed both decades ago — and this role inherits that discipline rather than reopening it. Reconciliation, directory, retry, and admission control are deployment concerns outside this document's scope.

Relationship to Existing Work Record layer. This document defines an exchange, not a record format: its attestations are designed to be carried in existing agent action records — the Agent Action Capsule supplies the disposition vocabulary, effect binding, and registration path this document relies on, and its selective-disclosure profile applies to cross-boundary privacy (). Accountability without a third party. The general mechanism this document specifies — two parties each holding a record of an exchange, each carrying the counterparty's signed acknowledgment, so that a unilateral alteration is detectable without a trusted arbiter — is not new. established, nineteen years earlier, that nodes in a distributed system can hold each other accountable for Byzantine faults by maintaining witnessed, tamper-evident logs of their message exchanges, with no assumption of a trusted third party. This document does not claim to originate that general shape; it specifies, at the agent-action layer, what PeerReview's node-to-node accountability protocol does not: (a) an agent-action vocabulary and framing — request and action attestations, deterministic constraint evaluation at an effect boundary, and a verdict-complete disposition set, rather than a general-purpose secure logging protocol for arbitrary distributed-system state; (b) asymmetric endings that distinguish a countersign explicitly refused from a counterparty that stayed silent (delivery_unconfirmed, counterparty_timeout; ) — a distinction PeerReview's fault model does not draw; and (c) a registered, third-party-verifiable form — records are registered with a SCITT Transparency Service () and bound by content digest, so that a party who trusts neither organization can verify inclusion and non-equivocation directly, rather than relying on PeerReview's peer-witness overlay of mutually monitoring nodes. Delegation receipts. binds a principal (the delegating user) to an authorization before any action, on one side of the boundary. This document binds two organizations to a specific action at the moment of action. The two compose: a request attestation may reference the delegation receipt authorizing the requesting agent. Remote attestation. RATS attests platform and workload state — what software is running where. This document attests actions — what was requested and what was done. A deployment may use RATS evidence to strengthen confidence in a counterparty's agent runtime; the two are orthogonal layers. Audit and approval records. The audit architecture describes recording agent interactions across parties, and records human authorization of high-risk actions; both are complementary record sources this exchange can feed and reference. The accountability composition describes how such records compose by shared action digest; a bilateral record naturally fills its cross-party leg. Agent Transfer Protocol (AGTP) defines attestation within a dedicated transport, via a CONFIRM method producing a signed acknowledgment of a prior action and an Attribution-Record header for audit. The bilateral attestation specified here differs in three respects: it is transport-agnostic (a SCITT Signed Statement that verifies identically over HTTP, A2A, MCP, or AGTP); it is bilateral in the strict sense — each party holds the other's signed attestation over the same action digest, rather than a one-sided acknowledgment; and each record is registered with a Transparency Service, so a party trusting neither agent can verify existence and non-equivocation. The two compose: an AGTP CONFIRM MAY carry and register a capsule. binds delegation-authorization references into the capsule payload as namespaced extensions, complementing both this profile and the base Agent Action Capsule profile by shared action digest.

Security Considerations

Identity Is the Floor The evidentiary weight of a bilateral record is bounded by the binding of keys to organizations. This document inherits, and does not solve, the organizational-identity problem; it requires only that the credential chain to a root the relying party accepts, and that identity be bound to the record, not merely the transport session.

Half-Completed Exchanges A party that aborts mid-exchange (requests, then never acknowledges the decline; performs, then withholds the action attestation) creates an asymmetric record. Timeout dispositions and registration deadlines bound the asymmetry: an unacknowledged attestation registered with a timeout marking is itself evidence of the counterparty's non-completion. Repeated non-completion is a property a relying party can establish from the records it holds; what it does about it is that party's decision, and this document neither scores counterparties nor defines a vocabulary for doing so.

Downgrade Attacks If degraded operation is permitted, an attacker prefers to be recorded at reduced assurance. Reduced-assurance records MUST be unambiguously marked, acceptance of degraded exchanges is a policy decision of the performing party, and consumers SHOULD weight degraded records accordingly. Silent downgrade is the failure mode to design out. A performing party MUST NOT accept an exchange at reduced assurance without explicit policy authorization to do so; policy MUST be configured, never inferred from the absence of a request attestation.

Replay and Cross-Binding Nonces and digests bind each attestation to one request instance; an action attestation MUST NOT be verifiable against any request other than the one it references. Specifically: if a request attestation's requester_org or action_digest differs from the performing party's record at the time it evaluates constraints, the performing party MUST reject the exchange and produce a denied attestation, not a reduced- assurance indicator. The distinction matters: reduced assurance records a capability gap; denial records a protocol violation. Two independent verifiers deriving disposition from the same canonical bytes MUST reach the same verdict.

Pre-Registration of Candidate Attestations A party that can write records freely can write several in advance — one for each outcome it might later prefer to claim — and disclose only the convenient one. Every disclosed record is then genuine, correctly signed, and correctly registered; nothing has been forged, and no integrity check detects anything. Registration does not prevent this. An append-only log establishes that a record existed at a time and has not changed since; it does not establish that the record was the only one written, or that its author believed it. The bilateral exchange resists this structurally rather than by detection. The at-most-one rule of means a performing party cannot hold a set of alternative action attestations for one request and reveal whichever suits: each alternative would have to reference a distinct request attestation, and each request attestation is signed and held by the other party. Producing a set of candidates therefore requires the counterparty's participation in producing the set. The same property is what a unilateral record lacks, and the limit should be stated plainly: a party acting alone, keeping its own records, with no counterparty entitled to ask what else it wrote, can pre-write candidates and disclose one. Bilateral attestation narrows that for exchanges it covers. It does not close it for records made outside an exchange.

Commitments and Predictable Values A digest establishes that its author held the digested bytes only to the extent that those bytes could not have been predicted. Where an attested object commits to a value drawn from a small enumeration or an otherwise constrained space — a fixed success indicator, a bounded status, a short identifier — a party MAY compute that commitment before observing the value, and a verifier cannot distinguish a commitment made before observation from one made after. "Bound to an observed value" is therefore a claim about entropy as much as about ordering. The bilateral construction resists this because an action attestation references the counterparty's request attestation by digest, and a signature over terms chosen by the other party is not predictable in advance. Profiles that derive a record from one party's observation alone do not inherit that property, and SHOULD ensure that the values they digest include a component the recording party does not choose. See also the low-entropy digest considerations of .

Key Establishment This document does not specify how parties establish mutual trust in each other's organizational keys. First-use acceptance (TOFU) is a documented-risk convenience — it does not establish verifiable organizational identity and MUST NOT be treated as conformant with the identity requirements of this document. Conformant deployments bind signing keys to organizational identity via a credential chaining to a root the relying party accepts, independent of the communicating parties' infrastructure.

Key Compromise and Revocation A signature valid at attestation time may be produced under a key compromised by verification time. A verifier SHOULD be able to establish key validity as of the attestation's registration time, not only at verification time; revocation and rotation semantics for organizational keys are inherited from the identity layer and are out of scope here, but a record without a registration time cannot support this distinction.

Canonicalization and Hash Agility Because every binding is by digest, the canonicalization of the attested objects is security-relevant: divergent serializations of the "same" terms produce different digests, and ambiguous canonicalization enables terms-substitution disputes. The failure is not that implementations choose badly; it is that two implementations can agree by convention and then silently diverge when the convention is never written into the bytes either of them signs. A future revision fixing wire encodings MUST therefore require the canonicalization to be declared by identifier inside the signed object, and MUST require a verifier to apply the declared construction rather than inferring one from the object's shape. RFC 8785 JCS is the expected construction; naming it is what makes divergence detectable instead of silent. The hash function is part of the named construction, so agility comes from naming a new construction, never from reinterpreting an existing name. Until wire encodings are fixed, implementations SHOULD document the canonicalization they apply and treat any divergence from a counterparty as a protocol error. An implementation that hard-codes a canonicalization without declaring it interoperates only with implementations that made the same unstated choice.

Verification-Cost DoS Verifying a request attestation (identity-chain plus Receipt inclusion) is more expensive than producing one. A performing party SHOULD be able to cheaply reject unverifiable request attestations before performing full verification, so request-attestation flooding cannot exhaust a performer at the effect boundary.

Privacy Considerations A bilateral record discloses, by construction, that two organizations transacted — to each other, and if registered with cleartext identifiers, to anyone. Deployments SHOULD register commitments rather than cleartext (selective-disclosure structures per ), disclose material terms only to the counterparty and auditors, and treat counterparty identity itself as a selectively-disclosable field where the use case allows. Correlation of registered records across a party's exchanges (client-list reconstruction) is the residual risk; mitigations are TBD, and any layer that aggregates these records faces the same problem from the consumption side.

IANA Considerations This document has no IANA actions at this time. A future revision defining wire encodings is expected to register media types for the four exchange objects and a registry for reduced-assurance indicator values. TBD.

References Normative References CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement). Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. Action State Group, Inc. MyAuberge K.K. EMILIA Protocol, Inc. Independent Tyche Institute Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. Action State Group, Inc. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. Action State Group, Inc. This document normatively profiles the per-field selective-disclosure extension point reserved in draft-mih-scitt-agent-action-capsule-01 Section 9.2 (Selective Disclosure). It defines the salted-hash commitment encoding, decoy-digest construction, disclosure format, producer requirements, and verifier checks for selectively disclosable fields in Agent Action Capsule payloads. The mechanism follows the SD-JWT selective-disclosure model (RFC 9901) — salted- hash commitments, decoy digests, and disclosed [salt, name, value] triples — using JCS (RFC 8785) canonicalization, which is already the base Capsule profile's canonical form. SD-JWT (RFC 9901) is the JSON form; SD-CWT (draft-ietf-spice-sd-cwt) is the CBOR/dCBOR sibling. Because the Capsule payload is JSON, this profile uses the SD-JWT (JSON) construction, cited alongside the SPICE WG's SD-CWT work for SCITT-ecosystem consistency. Verifier checks are deterministic and reproducible from the Capsule bytes plus a provided disclosure set alone; no clock, network access, model invocation, or external lookup beyond the provided disclosures is required. Authproof This document defines the Agent Delegation Receipt: a signed record of what a human principal authorized an AI agent to do, for how long, and under what instructions. The receipt carries a scope, hard boundaries, a validity window, and a hash of the operator's stated instructions, all signed by the authorizing key. Version -11 replaces the draft's earlier custom signature format with two standard profiles: a JWS profile (RFC 7515) over JCS-canonicalized JSON (RFC 8785) as the primary wire format, and a COSE_Sign1 profile (RFC 9052) for constrained environments. It also specifies scope attenuation rules for multi-agent delegation chains, a revocation registry model with cascade semantics, and the limitations of what receipts can and cannot prove. Version -12 resolves the unknown- fields question raised on the IETF oauth mailing list: authorization fields are closed (verifiers reject unknown top-level body fields rather than silently ignoring them), the "metadata" object is the defined extension point, and one-time-use receipts fail closed without a durable consumption store. Version -13 incorporates independent-implementation feedback: it pins the orchestratorSignature verification key to the sub-receipt signer's key, states the receipt-issuance computation order explicitly, and guides issuers on default boundaries versus explicit allowances. Version -14 adds a pointer to content profiles for verification of what the agent produced, following implementer feedback. Version -15 adopts the grant/execution vocabulary of [CHEN-AGENT-USE-CASES]: the receipt as Execution Layer Evidence for a Grant Layer Authority. It adds delegatee holder binding for sub-receipts -- a parent names the delegatee's public key, closing a bearer-copy issuance gap found in review -- deprecates orchestratorSignature as redundant, sketches an OAuth authorization_details binding so a token can reference its receipt, and states normative custody requirements for the authorizing key. The delegateeKey field is a wire-format addition; -14-era verifiers will reject receipts carrying it, which is the intended fail-closed version behavior. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Nomotic, Inc. AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as Agent Group Messaging Protocols (AGMP), including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP is a runtime contract negotiation substrate (RCNS): a transport that fixes only a eighteen-method protocol floor and negotiates any additional method surface at runtime between agent and server in a single round-trip, governed by the AGTP-API companion specification [AGTP-API], which defines the curated method catalog, path grammar, endpoint primitive, and synthesis semantics. Version 07 confirms the IANA-registered agtp:// URI scheme and IANA-assigned port 4480 for TCP/TLS and QUIC, formalizes Form 1a URI grammar (agtp://{agent-id}@{host}) for direct addressing, renames the Agent Manifest Document to the Agent Identity Document with an enumerated schema, redesigns the protocol-defined method floor to a 12-method set organized as six cognitive verbs (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) and six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY), establishes AGTP as a substrate for higher-level agent frameworks (MCP, A2A, ACP) carried as content types inside AGTP method invocations, renumbers AGTP-specific status codes out of HTTP- assigned space to avoid semantic collision, mandates explicit Content-Length framing with a prohibition on TLS socket-level half- close, adds a .well-known/agtp bootstrap convention per RFC 8615, deprecates the AGIS reference and the proposed AGTP-Methods specification by folding both into the unified AGTP-API contract layer, adds status codes 405 (Method Not Allowed), 459 (Method Violation), and 460 (Endpoint Violation) per the AGTP-API contract model, and adopts "Agent Genesis" as the canonical term for the permanent signed origin document. Version 06 prepared the IANA Service Name and Port Number application and consolidated the URI scheme registration. Version 05 restored the canonical Agent-ID as the primary identity primitive and decoupled Trust Tier 1 verification from DNS as a sole requirement. A canonical Agent-ID is derived from the agent's Agent Genesis hash and is authoritative in every AGTP protocol operation. Three equivalent verification paths are recognized for Trust Tier 1: DNS-anchored verification via RFC 8555 ACME challenge, log-anchored verification via Agent Genesis inclusion in an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), and hybrid verification combining DNS control with blockchain address ownership. Version 04 introduced normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant- side identity model that complements AGTP's agent-side identity model. AGTP transport bindings for TCP/TLS and QUIC are specified in [AGTP-BINDINGS]. AGTP is designed to be composable with existing agent frameworks, not to replace them. Glyphzero, Inc. The Agent Action Capsule (AAC) profile (draft-mih-scitt-agent-action- capsule) records what an autonomous agent actually did -- executed, blocked, denied, errored, or timed out -- with a structural binding that prevents an attempt from being presented as a completion. AAC deliberately does not define the authority that permitted an action; it carries that authority as an opaque reference. Two companion profiles supply what that reference can point to: a per-action authorization profile (draft-rampalli-aiagent-authz-hmac) records that an action was permitted (the "may"), and a memory-provenance profile (draft-rampalli-aiagent-memory-provenance) records the source and trust state of the belief on which the agent acted (the "why- believed"). This document specifies how the latter two are bound into an AAC Capsule. It defines (a) what the AAC "disposition.authority" reference MAY resolve to, (b) a namespaced, payload-only extension carrying an authorization-token reference, a memory chain root, and a quarantine attestation, and (c) an OPTIONAL divergence-class value, drawn from the per-action profile, that explains a non-executing AAC verdict. The binding uses only mechanisms AAC already provides -- the opaque authority reference and the payload-extension namespacing convention -- and changes neither AAC's closed protected-header claim set nor its Class 1 verification. The result is a single verifiable record that answers "may," "did," and "why-believed" together. Alter Meridian Pty Ltd This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers itself, on its own behalf, as an economic principal in a transparency service, and by which that registration is the specific act that makes the agent eligible to be paid for subsequent reads of its own identity record. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure, so that admission remains a deterministic function of committed inputs and stays replayable by an auditor. The profile is positioned against the current agent- identity drafts, which either require a human principal at the root of the chain or leave the owner-less case undefined; it occupies that undefined seam without contradicting them. This document is Informational. MPI-SWS and Rice University MPI-SWS MPI-SWS Proceedings of the 21st ACM SIGOPS Symposium on Operating Systems Principles (SOSP '07), pp. 175-188

Acknowledgments This exchange pattern owes its framing to discussions in the SCITT and agent-accountability communities, and composes with the work of the authors cited above. Iman Schrock (EMILIA Protocol) contributed the constraint-record obligations in this revision: constraint-set pinning (MUST), input-commitment digest (SHOULD), and completeness (MUST). Blake Morrison contributed the party-identifier MAY sentence in the Conventions and Definitions section, enabling party identifiers to resolve to registration entries admitted on the same Transparency Service.