Agreement Evidence for Multi-Party Agent Negotiation

1.1. Design Goals

This document has four goals:¶

1. Define evidence that a named set of parties reached a named negotiation outcome.¶
2. Require all listed parties, not merely the holder, to bind that outcome.¶
3. Carry useful behavioral signals without raw negotiated terms.¶
4. Require both signer-asserted validity and an independent relying-side freshness policy.¶

1.2. Non-Goals

This document does not define:¶

• real-world or legal identity verification;¶
• mandates, delegation chains, or authorization-envelope formats;¶
• payment processing, settlement finality, or proof of delivery;¶
• network transport, routing, discovery, or service availability;¶
• a general-purpose action or access-control receipt;¶
• reputation scoring, Sybil resistance, or a centralized reputation service;¶
• a general cross-format evidence taxonomy, composer, or sufficiency verdict;¶
• end-to-end encryption; or¶
• proof that every statement in an attestation is objectively true.¶

2.1. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Definitions

Party:

An autonomous agent participating in a negotiation.¶

Offer:

A proposed assignment of values to one or more terms. An offer can be complete, partial, conditional, or a bundle.¶

Agreement:

The final term values accepted by all parties, together with the signed transcript that records how those values were reached.¶

Negotiation transcript:

The ordered set of signed protocol messages for a session, connected by predecessor hashes, in the form the negotiation protocol defines. This document defines no transcript format.¶

Agreement attestation:

A signed, privacy-preserving statement about a completed negotiation session. It identifies the outcome and behavioral signals and does not carry the negotiated term values. This document calls it "the attestation" where no ambiguity arises.¶

Issuance snapshot:

The value derived from an attestation by the procedure in Section 6.1, over which all party countersignatures are computed.¶

Holder:

Any entity in possession of an attestation, whether or not it is a party.¶

Outcome-bound:

A property of an attestation for which every party listed in parties[] has a resolvable and valid countersignature over the same issuance snapshot.¶

Deployment profile:

The set of choices a deployment makes outside this document and states in its own specification. It names the key-binding mechanism and the revocation source if any. This document defines neither.¶

Terminal state:

The single result Section 10 exposes to application policy. This document defines exactly four terminal states, defined immediately below, and defines no other result label. A verifier reports exactly one of them for any received artifact.¶

not-bound:

The terminal state of an artifact the verification procedure rejects at any step, and of an attestation at version 0.5.0 or later whose outcome binding Section 6.2 does not establish. It carries no outcome-binding claim.¶

bound-only:

The terminal state of an attestation that is outcome-bound, and whose revocation status the verifier did not determine. The status is undetermined for any of three reasons: the deployment profile names no revocation source, the named source was unavailable, or the named source supplied a record that cannot be interpreted under the deployment's own definition of that source. All three reasons produce this one state.¶

current:

The terminal state of an attestation that is outcome-bound, passed the verification procedure's freshness checks, and whose named revocation source answered and reported the attestation as not revoked.¶

legacy:

The terminal state of an artifact whose concordia_attestation value is well formed and below 0.5.0. Such an artifact is retained as a record of its own contents. It is never outcome-bound and never current, and the verification procedure runs no signature, binding, temporal, or revocation step over it.¶

Relying party:

A verifier that decides whether to act on an attestation or related artifact.¶

3.1. Negotiation Lifecycle

Implementations of the negotiation protocol that produces these artifacts typically progress through the states PROPOSED, ACTIVE, AGREED, REJECTED, EXPIRED, and DORMANT, exchanging signed offers, counteroffers, acceptances, commitments, declines, and withdrawals, and enforce session, offer, and round limits. That protocol is out of scope for this document, which specifies only the evidence artifacts. No requirement of this document names a message format.¶

This document does not reproduce the offer grammar or the state-transition table. See Section 14.6 for how this scope choice relates to ongoing work in the broader agent-protocol space.¶

3.2. Two Evidence Surfaces

There is no third standalone object that carries both private term values and public evidence. The protocol intentionally exposes two signed surfaces for different audiences:¶

• Negotiating parties retain the final commit messages that close a negotiation and record the Agreement as defined in Section 2.2. Those messages contain the actual accepted term values and are individually signed and hash-chained into the transcript.¶
• A third party that needs proof an agreement was reached, but does not need the term values, receives the attestation defined in Section 4.¶

The attestation's outcome, party set, chain head, and message count record what the parties jointly bound about the session. The format provides no member for a term value. The constraints in Section 7 then obligate a producer not to place a term value in the free-text members the format does provide, which are category and summary. Those constraints bind the producer, and a verifier cannot detect a violation of them by inspecting a received object, so a relying party that reads an attestation learns that no member is defined to carry a term value and does not learn that no term value was smuggled into one. An attestation whose outcome.status is rejected, expired, or withdrawn records that no agreement formed, so an attestation is evidence about a session rather than proof that an agreement exists.¶

An attestation defined by this document is produced when a negotiation concludes, and it records what the parties bound at that moment rather than a commitment fixed in advance of some later evaluation. A relying party that requires a commitment fixed before a decision obtains that commitment from a separate artifact, for example an approval receipt over the digest of a canonical Offer as described in Section 9.1, and this document does not define one.¶

4.1. Attestation Members

This section defines the attestation produced at the conclusion of a negotiation session. Whether a session must produce one is a property of the negotiation protocol and is out of scope.¶

An attestation defined by this document contains exactly the following members, of which concordia_attestation, attestation_id, session_id, timestamp, outcome, parties, meta, and transcript_hash are required at every version:¶

• concordia_attestation, the format version, a string of exactly three dot-separated non-negative decimal integers without leading zeros. Artifacts defined by this version carry "0.6.0". A verifier compares two versions by numeric comparison of the three components in order.¶
• attestation_id, a unique artifact identifier;¶
• session_id, the negotiation session identifier;¶
• timestamp, the issuance time;¶
• outcome, including status and round count;¶
• parties[], including each party's agent identifier, role, behavioral counters, and party signature;¶
• meta, containing only the bounded context members permitted by Section 7;¶
• transcript_hash;¶
• chain_head and message_count;¶
• validity_temporal;¶
• countersignatures; and¶
• summary and references, each optional at every version.¶

The member name concordia_attestation is retained from the deployed base of artifacts that this format already describes. Renaming it would invalidate every signature computed over an existing artifact.¶

Section 4.4 is normative. It defines every member listed above, its JSON type, its encoding, its cardinality, and its value constraints. The identifier urn:concordia:schema:attestation:v0.5 names the machine-readable form of the member set of the 0.5.0 predecessor of this format and is informative. It is registered in no IANA registry, no requirement of this document reads it, and it appears here only to name the form the 0.5.0 line published. The 0.6.0 member set differs from that of the 0.5.0 line by the removal of three members: the fulfillment member of the attestation root, the extensions member of a reference element, and the window mode of validity_temporal. On the members it retains, this document adds constraints that a 0.5.0 implementation does not apply. Where a published schema document and this document disagree, this document governs.¶

4.2. Outcome Vocabulary

outcome.status is one of agreed, rejected, expired, or withdrawn. The outcome also carries the number of rounds and the session duration, and can carry the term count and the resolution mechanism, as defined in Table 2. Those values describe the session; they do not expose the negotiated terms.¶

4.3. Behavioral Signals

Each parties[] element carries a behavior object holding the members defined in Table 4: offers_made, concessions, concession_magnitude, signals_shared, constraints_declared, constraints_violated, reasoning_provided, withdrawal, and response_time_avg_seconds. It carries no other member. These are evidence inputs and not a protocol-defined reputation score. A relying party MAY calculate its own score or ignore them.¶

4.4. Field Definitions

This section is normative. It defines the complete member set of an attestation and of every object nested inside one. An implementation of the attestation format and of its verification can be written from Sections 4 through 8 and 10 of this document with two external inputs named by the deployment profile: the key-binding mechanism, which step 3 of Section 10 requires for every verification, and the revocation source of step 7, if currency is sought. This document defines neither.¶

Encodings are pinned as follows.¶

• A signature value is the 64-octet Ed25519 [RFC8032] signature of [RFC8032], Section 5.1.6, encoded with the base64url alphabet of [RFC4648], Section 5 with the two trailing padding characters that section requires for a 64-octet input. The encoded value is therefore exactly 88 characters: 86 drawn from that alphabet followed by two padding characters. The final encoded group carries four unused bits, and those bits MUST be zero. A recipient MUST reject a signature value of any other length, a value whose padding is absent or misplaced, a value carrying any character outside that alphabet, a value carrying whitespace, and a value whose unused bits are not zero. This is the encoding the 0.5.0 line already produces, retained so that no existing signature value changes form. Two signature values are equal when their 64 decoded octets are equal, and a recipient MUST compare the decoded octets rather than the encoded characters.¶
• A public key is the 32-octet value of [RFC8032], Section 5.1.5. No member defined by this document carries a public key.¶
• A timestamp is an RFC 3339 [RFC3339] date-time whose time-offset is the single character "Z". A recipient MUST reject a numeric offset, including "+00:00", and MUST reject a fractional second of more than three digits.¶
• chain_head and transcript_hash are SHA-256 [RFC6234] digest strings, rendered as the literal "sha256:" followed by 64 lowercase hexadecimal characters. transcript_hash is opaque to the verifier this document defines: its preimage is undefined here, no check in this document reads it, no verification result this document defines makes any claim about it, and a verifier neither recomputes nor compares it. It is retained because the 0.5.0 line carries it. chain_head is an opaque value in the issuance snapshot. Its preimage and computation are defined by the negotiation protocol that produced the transcript, not by this document. The verifier this document defines neither recomputes nor compares it; the verified claim is that every listed party countersigned that string and message_count in the same issuance snapshot.¶
• Every string member defined by this document is carried in Unicode Normalization Form C [UAX15]. A recipient MUST reject a string member whose received value differs from its own Normalization Form C, and MUST compare two identifier strings only after both are in that form. Where this section states a length in characters, the unit is the Unicode scalar value. Where it states a length in octets, the unit is the octet of the UTF-8 [RFC3629] encoding of the normalized value.¶
• Where this section says a member carries no whitespace, that member MUST NOT carry a character with the Unicode White_Space property, and MUST NOT carry a character in the ranges U+0000 to U+001F, U+007F to U+009F, U+200B to U+200F, or U+2028 to U+202E.¶

This format is extended by publishing a new version under Section 4.1 rather than by adding members. The value vocabularies of a reference's type and relationship members are the exception: a recipient MUST preserve a type or relationship value it does not recognize as an opaque string rather than rejecting it, so that a later version's relationship survives a round trip through an earlier implementation.¶

A parties[] element's signature member is removed before the issuance snapshot is derived (Section 6.1). This document defines no verification step over it, and a verifier MUST NOT treat its presence or its validity as evidence that an outcome is outcome-bound. Outcome binding rests on countersignatures alone, as Section 6.2 specifies.¶

The category grammar is a dotted lowercase taxonomy path. Each segment is one or more characters drawn from a to z, 0 to 9, underscore, and hyphen, and a single full stop separates adjacent segments. The whole value is at most 64 octets.¶

A value_range value is one of the bucket tokens 0-100, 100-500, 500-1000, 1000-5000, 5000-10000, 10000-50000, 50000-100000, 100000-500000, 500000-1000000, or 1000000+, followed by a single underscore and a three-letter uppercase currency code, for example 1000-5000_USD. The bands are enumerated so that an exact price cannot be encoded as a degenerate range. A recipient MUST reject any other value.¶

A reference element carries a type drawn from receipt, chain_session, predicate, and mandate, and a relationship drawn from supersedes, extends, fulfills, and references. A recipient preserves an unrecognized value of either member as an opaque string, as stated above. A reference element carries no member other than the six of Table 6. This version defines no extension point inside a reference element; a later version that needs one introduces it by publishing a new format version, on the terms of Section 4.1.¶

The validity_temporal object carries a mode discriminator and the members that mode requires. Section 8.3 defines the two modes, the members each one carries, and the interval semantics a verifier applies. The object carries no member other than those its mode requires.¶

5.1. Canonical JSON

Objects defined by this document are JSON [RFC8259] values that use the JSON Canonicalization Scheme (JCS) [RFC8785]. A signer and verifier MUST canonicalize the same logical object to identical UTF-8 [RFC3629] bytes before signing or verification. Implementations MUST reject values that cannot be represented under Section 4.4 and the canonicalization rules.¶

A verifier recanonicalizes the received object under JCS and verifies every signature over the recanonicalized bytes. All numeric members defined by this document are integers in the range 0 to 2^53-1 inclusive, except concession_magnitude, which is a number between 0.0 and 1.0 inclusive, and response_time_avg_seconds, which is a number of 0 or greater. Where this document states a narrower range for a particular member, including the positive duration_seconds of Section 8.3 and the bounds of Section 11.7, that narrower range governs and the general range above does not admit a value the narrower range excludes. A recipient MUST reject a numeric value outside its stated range, MUST reject an object in which a member name occurs more than once, as detected during parsing and before any duplicate-resolution rule is applied, and MUST reject input that is not well-formed UTF-8 or that contains an unpaired surrogate.¶

5.2. Signature Verification Criteria

Implementations MUST verify Ed25519 [RFC8032] signatures as specified in Section 5.1.7 of [RFC8032] using the cofactorless equation, and MUST reject a signature whose R or S component is not canonically encoded, whose S is not reduced modulo L, or whose public key is not a canonically encoded point of order L. These criteria apply to every signature a verifier checks under this document, which is each party countersignature of Section 6.1.¶

A signature required by this document is computed over canonical payload bytes that carry no context string separating a countersignature from any other Ed25519 signature made with the same key. A deployment that reuses keys across protocols relies on those payload shapes being distinguishable in practice rather than on a separation this document enforces. Section 11.4 states that bound.¶

6.1. Countersignature Payload

The countersignature payload is the JCS canonicalization of the issuance snapshot. To derive it, an implementation MUST:¶

1. begin with the fully assembled attestation;¶
2. remove every member named signature recursively at every depth;¶
3. remove the top-level countersignatures member; and¶
4. canonicalize the result using JCS.¶

No countersignature covers itself or a sibling countersignature. Every party therefore signs byte-identical, mutually independent payload bytes. Those bytes carry no context string that separates them from any other payload a party signs with the same key, on the terms stated in Section 5.2 and Section 11.4.¶

countersignatures is a JSON object whose member names are the agent identifiers appearing in parties[] and whose values are Ed25519 signatures over the payload derived above, encoded as Section 4.4 pins them.¶

The member set of an attestation is closed: an attestation carries only the members defined in Section 4.4, at the root and at every nested object. Step 2 of Section 10 therefore rejects an attestation carrying any member Section 4.4 does not define, including a member named signature at a location Section 4.4 does not define, before any signature is verified. The removal rule in this section operates on that closed set.¶

6.2. Outcome-Binding Verification

For concordia_attestation version 0.5.0 or later, a verifier MUST NOT credit an outcome as outcome-bound unless:¶

1. parties[] contains at least two entries;¶
2. every entry's agent identifier is distinct;¶
3. countersignatures is present;¶
4. the member names of countersignatures are exactly the set of agent identifiers in parties[], with no additional and no missing member;¶
5. every party listed in parties[] has exactly one corresponding signature;¶
6. the verifier resolves the key for every listed party; and¶
7. every signature verifies over the payload in Section 6.1.¶

The all-listed-parties rule, together with the minimum of two entries, prevents a holder from changing the outcome, removing a counterparty row, and re-signing with only its own key.¶

An attestation carries no signature distinct from the party countersignatures, and it names no assembling role that a verifier could check. Its authenticity rests entirely on the countersignature of every listed party over the issuance snapshot, so an attestation whose outcome is not credited as outcome-bound is not authenticated by anything in this document.¶

An attestation whose concordia_attestation value does not match the grammar in Section 4.1 is rejected at step 2 of Section 10 and is not retained.¶

An artifact whose version is well formed and below 0.5.0 leaves the procedure of Section 10 at step 2 with the terminal state legacy, and no check of this section is applied to it. Such an artifact MAY be retained as a record of its own contents. Its outcome MUST NOT be credited as outcome-bound, and it MUST NOT be reported as current. No requirement of Section 8 applies to it, because every requirement there is defined for version 0.5.0 and later.¶

8.1. General Relying-Side Obligation

A currently valid signature is not evidence that the signed claim remains true. The freshness requirements below determine whether an attestation may be relied upon.¶

A relying party MUST configure a maximum evidence age not exceeding 90 days, a maximum accepted validity lifetime not exceeding 90 days, and a clock-skew allowance not exceeding 300 seconds, and MUST reject evidence that exceeds any of them. A relying party MAY configure tighter values. Throughout this document 90 days is 7776000 seconds, which is 90 multiplied by 86400, and is not a calendar quantity.¶

Every requirement of Section 8, including the evidence-age anchor defined below, is defined for an attestation at version 0.5.0 or later and for no other artifact. An artifact whose version is well formed and below 0.5.0 reaches the terminal state legacy at step 2 of Section 10, so no anchor is computed for it and no ceiling of this section is applied to it.¶

Evidence age is the verifier's current time minus the evidence-age anchor defined below.¶

A relying party MUST enforce its own maximum evidence age independently of the signer's asserted validity window, and MUST reject a signer-asserted timestamp or interval start that is future-dated beyond that clock-skew allowance. The evidence-age anchor is the earlier of the attestation's timestamp member and the start of its validity_temporal interval. A verifier MUST enforce that finite skew bound and fail closed outside it, whatever the quality of its clock synchronization.¶

A relying party MUST reject an attestation whose validity_temporal interval has ended at the time of verification.¶

A relying party MAY apply a tighter freshness bound than the signer asserted.¶

8.2. Producing-Side Obligation

A party MUST NOT countersign an attestation whose validity_temporal lifetime exceeds 90 days as Section 8.1 defines that quantity. That lifetime is the length of the interval that Section 8.3 defines for the stated mode, which is the span between from and until in absolute mode and the value of duration_seconds in relative mode. A party MAY apply a shorter maximum.¶

8.3. Required Temporal Validity

validity_temporal is REQUIRED on every attestation at version 0.5.0 or later. It is a JSON object carrying a mode member whose value is either "absolute" or "relative", and the members that mode requires. All timestamps are RFC 3339 [RFC3339] date-time values encoded as Section 4.4 states. When mode is "absolute", the members from and until are present, the interval is [from, until], and the lifetime is the span between those two times. When mode is "relative", the members from and duration_seconds, a positive integer, are present, the interval is [from, from + duration_seconds], and the lifetime is duration_seconds. Each mode therefore has exactly one interval and exactly one lifetime, which is the quantity the caps of Section 8.1 and Section 8.2 bound. A verifier MUST reject a validity_temporal object whose mode member is absent or carries another value, whose members for the stated mode are absent, which carries any other member, or whose interval is empty or reversed.¶

An artifact whose version is well formed and below 0.5.0 reaches the terminal state legacy at step 2 of Section 10 and is never read for this member. An artifact at version 0.5.0 or later that omits this member is rejected at that step with the terminal state not-bound.¶

8.4. Single Use

An attestation defined by this document carries no single-use semantics, and the temporal validity of Section 8.3 alone permits an unbounded number of effects inside the signed window. A relying party that treats one attestation as grounds for a consequential effect SHOULD keep a consumption record for that attestation, keyed by its attestation_id, inside its own accounting domain, and consult that record before admitting a further effect.¶

This document defines no atomic check-and-record operation, no concurrency rule, and no maximum, so two simultaneous decisions inside one accounting domain, and two decisions in separate domains, can each admit an effect against the same attestation. A deployment that needs enforced single use obtains it from a mechanism that defines those semantics, for example the budgeted capability described in Section 14.9.¶

9.1. ApprovalReceipt

An ApprovalReceipt records a human or policy approval decision over the digest of the canonical form of an Offer as defined in Section 2.2; that companion format specifies how the digest is computed. approve and deny are both binding signed decisions. The receipt can reference the mandate it fulfills without defining the mandate format. It is not proof that the approved transaction executed.¶

9.2. FulfillmentAttestation

A FulfillmentAttestation records whether an agreed exchange was fulfilled, fulfilled with mediation, failed, or remained disputed. It references the agreement attestation it fulfills. It is distinct from payment settlement evidence: payment settled is not proof of delivery, and fulfillment is not proof of payment finality.¶

9.3. RevocationRecord and Cascade Decision

A RevocationRecord identifies a specific artifact, its effective time, and whether revocation is limited to that artifact or cascades to dependents. In that companion format, a verifier recomputes any committed cascade decision from the retained raw artifact bytes. This document states no requirement over cascade traversal, because it defines no revocation record, no authority rule, and no cascade graph. A cascade decision is a scoped verifier result over the artifacts defined or referenced by this document; it is not a general-purpose cross-format composition or sufficiency engine.¶

11.1. Dishonest Negotiation Party

A party can issue a false behavioral self-report. Requiring every listed party's countersignature prevents one holder from rewriting the shared outcome, but it does not make every self-described behavioral detail objective truth. Applications must distinguish jointly bound outcome members from party-level self-reports.¶

The outcome an attestation carries is what the listed parties jointly asserted at issuance. This document defines no procedure for re-deriving an outcome from the transcript and no check that the transcript's final message agrees with outcome.status, so a set of parties that agree to misdescribe their own session produces evidence this document's checks accept. Every check here is a check on what the parties bound together, and none is a check that what they bound is true.¶

chain_head is an opaque value in the issuance snapshot, and message_count is the count the parties countersigned with it. This document defines no check that derives the transcript, proves completeness, or establishes the order in which messages were created.¶

transcript_hash is opaque to the verifier this document defines. No check here reads it, and a verified result makes no claim about it beyond the fact that the listed parties countersigned a snapshot containing that string. chain_head is the digest string that the abstract and Section 1 name, but its preimage is not defined here.¶

A party can replay old but still correctly signed evidence. Required temporal validity and independent relying-side age limits reduce this risk; neither signature verification nor the signed window alone is sufficient.¶

11.2. Compromised Delivery Path

The negotiation messages of a protocol that produces an attestation are not protected by this document. A relay or mailbox can read offer terms and reasoning unless that separate protocol or transport protects them. Deployments MUST NOT describe this document as an end-to-end encryption protocol.¶

Countersignature verification detects modification of the attestation bytes. It does not prevent delay, suppression, traffic analysis, or denial of service. Session and offer timeouts bound how long a party waits and do not guarantee availability.¶

A holder that suppresses a relying party's access to a revocation source is not detectable by any check in this document. An attestation verified without a determination of revocation status is evidence that the parties bound an outcome at issuance, and it is not evidence that the outcome stands today.¶

11.3. Privacy Leakage

The closed schema provides no member for a raw deal term. The residual channel described in Section 7 remains, and it has two halves: the category taxonomy, whose grammar constrains shape rather than meaning, and the free-text summary, whose content constraint is a producing-side obligation a verifier cannot confirm. A producer that violates either obligation still produces an artifact that verifies. Correlation across stable agent identifiers, timestamps, categories, and session metadata can also reveal patterns even when individual term values are absent. Implementers SHOULD minimize retention and disclosure according to their deployment's risk model.¶

11.4. Key Compromise and Identity

This document does not define identity proofing, key discovery, key rotation, or key revocation. A deployment MUST define how keys are bound to agent identifiers and how compromise is detected and handled. Outcome binding proves control of the resolved keys. It does not prove the real-world identity or the authority of their holders.¶

A deployment that does not define key binding, rotation, and revocation cannot perform step 3 of Section 10 and therefore cannot verify an attestation defined by this document at all.¶

Signatures defined by this document are computed over canonical payload bytes with no context string distinguishing a countersignature from a negotiation message. A deployment that signs both with one key relies on the payload shapes being distinguishable in practice rather than on a separation this document enforces. Closing that gap would need a future version to introduce an explicit context string, and a version that did so would invalidate every signature produced under this one. This document specifies no such string and commits no future version to any particular construction.¶

Agent identifiers are compared as the normalized strings of Section 4.4. Two identifiers that a human reads as the same name but that differ after that normalization are different parties under this document, so preventing confusable identifiers is a property of the deployment's identifier issuance rather than of any check defined here.¶

Agreement evidence is long-lived by design, and this document anchors no external time source. A party key that is compromised or that becomes forgeable long after issuance can be used to produce an artifact that back-dates its own timestamp and validity_temporal members, and nothing inside the artifact distinguishes that artifact from one issued at the time it claims. The relying-side evidence-age ceiling of Section 8.1 bounds how long such an artifact remains useful to an attacker; it does not detect the forgery. A deployment that needs that detection anchors the artifact in an external append-only service at issuance.¶

11.5. Sybil Behavior and Completeness

This document does not prevent one actor from operating multiple agent identities. It also does not prove that a selectively disclosed set of attestations is a party's complete history. A verified aggregate can prove that the revealed set is internally sound and party-bound; it cannot prove the set is representative without an external append-only history anchor.¶

11.6. Post-Quantum Migration Path

Ed25519 [RFC8032] is the mandatory-to-implement signature algorithm for version 0.6.0 of this format, and this document does not define per-object algorithm negotiation: algorithm choice is fixed per profile version rather than negotiated on the wire, which removes the downgrade and attacker-choice failure modes that negotiation would otherwise introduce. [RFC7696] (BCP 201) discusses the tradeoffs of algorithm agility in general terms and is cited here for background. Agreement evidence is long-lived by design (see Section 8), so a signature algorithm that becomes cryptanalytically broken during an attestation's useful lifetime would retroactively weaken the probative value of evidence issued under it. [RFC9958] surveys the post-quantum signature landscape; ML-DSA and SLH-DSA are the NIST-standardized post-quantum signature algorithms most likely to be named by a future profile version of this format. This document does not adopt either algorithm, does not define a hybrid classical/ post-quantum signature mode, and does not add a negotiation field: the migration mechanism is a new profile version, consistent with the fixed-profile design this section describes.¶

11.7. Resource Limits

The limits of this section are relying-party requirements, and Section 10 states the step at which each one is applied. A verifier MUST reject, before parsing it, a received artifact larger than its configured maximum artifact size, and that configured maximum MUST NOT exceed 262144 octets. A verifier MUST reject an artifact whose JSON nesting depth exceeds 16. message_count MUST be an integer between 1 and 10000 inclusive, and a verifier MUST reject an attestation outside that range. The rejections of steps 1 and 2 of Section 10, which are the artifact-size cap, the nesting-depth cap, and the message_count range, run before any signature verification. The member caps of Section 4.4 bound the remaining attacker-controlled lengths inside the attestation: at most 64 parties, at most 32 references, at most 16 extension names, at most 256 octets in any identifier, and at most 1024 Unicode scalar values in summary. This document processes no transcript. The message_count cap instead bounds an attacker-controlled integer that applications may display, log, or use in policy.¶

Two listed parties do not imply two transcript messages. A single message can carry a jointly meaningful commitment, so message_count has a floor of 1 and the number of listed parties implies nothing about the number of messages.¶

14.1. Evidence Composition and Sufficiency

A general evidence-composition framework can treat a verified attestation as a native evidence component, alongside the ApprovalReceipt, FulfillmentAttestation, and RevocationRecord that Section 9 names. This document defines the attestation and defines none of those three: their member sets, signature preimages, and authority rules come from the Concordia Protocol Specification described in Appendix A or from whatever document a deployment names, and no requirement of this document reads a member of any of them. The verification procedure (Section 10) is authoritative for the attestation alone. An external composer decides whether a set of heterogeneous evidence is sufficient for its own relying policy.¶

This composition is optional. No normative requirement in this document depends on any particular composition framework or draft revision. Appendix C illustrates one such external composition model without creating a dependency on it.¶

14.2. Evidence Request and Refusal

A relying party can refuse an interaction with a structured challenge that describes missing evidence, a freshness requirement, accepted presentation profiles, and retry state. This document's artifacts can be consumed in that pattern without this document defining a competing challenge format: a party can decline a proposed session with a reason and later open or reactivate a session after obtaining the requested evidence. This document does not define a machine-readable outstanding-evidence vocabulary in the decline message.¶

14.3. Authority and Mandates

Authorization assertions and mandates describe what an agent is permitted to do before negotiation. This document describes what the parties negotiated and jointly bound afterward. A mandate can be referenced by an artifact defined in this document; the mandate format and authorization decision remain external.¶

This document places obligations on the party that relies on an attestation and places none on a policy evaluator deciding whether an action may proceed. Binding an evaluator in advance to decide against a specific prior commitment is a property of the authorization layer described in this section, and an implementation that requires it obtains it there.¶

14.4. Boundary-Decision and Action Receipts

Access-control and action receipts record what one boundary, gateway, or policy engine decided or observed. An attestation defined by this document records what multiple negotiating parties jointly bound. A deployment can produce both artifacts for the same broader transaction; neither substitutes for the other.¶

14.5. Settlement Evidence

Payment and ledger evidence prove rail-specific authorization, consumption, or finality. This document intentionally does not. Likewise, a FulfillmentAttestation as described in Section 9.2 does not prove payment finality. Together they can describe different parts of one transaction without collapsing their signer positions.¶

14.6. Relationship to the agentproto Working Group

The proposed IETF agentproto working group charter describes a standards-track agentic dialog management protocol (dialog correlation, lifecycle, and transport bindings), an informational reference architecture, and informational use cases and requirements. Its charter-ietf-agentproto-00-04, dated 2026-10-02, lists this out-of-scope item: "Audit data structures and their production, validation, or consumption, though dialog identifiers may be used in auditing." Its coordination section names, verbatim, "Evidence and transparency: SCITT, RATS, on software and hardware security" and, for identity and authorization, "Security: Web Authorization Protocol (OAuth), webbotauth, WIMSE."¶

The evidence objects defined by this document are not an agentproto deliverable and are not listed in its charter. This document touches the agentproto charter only at the evidence-and-transparency coordination point named above and at the dialog-identifier hook preserved in the out-of-scope line. This document defines no mapping from session_id to a dialog identifier, and it defines no dialog-management, transport-binding, session-lifecycle, or identity/authorization mechanism of its own.¶

14.7. Relationship to a Neutral Evidence-Composition Interface

A related effort defines a protocol-neutral interface for composing evidence across multiple agent-evidence formats. This document defines this specification's own artifact family; the neutral-interface effort defines a composition interface across formats. Neither is a normative dependency of the other, and this document does not describe, reference, or rely on that effort's schema, status, or publication venue.¶

14.8. Adjacent Multi-Signer Evidence Work

Other individual Internet-Drafts define multi-signer evidence for agent actions and transactions. [I-D.laxsharma-pact] defines a contract layer in which a buyer and a seller co-sign a JCS-canonicalized task contract; a Verdict is bound by digest to the Delivery it judges; and a Facilitator alone signs one Outcome Record per contract as input to reputation systems. That contract format binds pricing and scope terms directly into the signed object and does not specify an independent relying-side freshness discipline. [I-D.mih-agent-bilateral-attestation] defines a four-move exchange in which each of two organizations holds the other's signature over the same action digest; it covers a single directed action rather than a negotiated multi-attribute outcome, and its wire encoding is deferred to a future revision.¶

The attestation defined by this document differs from both: it binds an outcome reached through a multi-round, multi-attribute negotiation (Section 3); it structurally excludes negotiated price, quantity, date, and free-text term values from the signed object (Section 7); and it defines an independent relying-side freshness obligation (Section 8) that neither adjacent draft specifies. These efforts are complementary rather than competing; a relying party could in principle consume evidence from more than one of these formats for a single broader transaction.¶

14.9. Adjacent Requirements and Single-Issuer Evidence Work

[I-D.somoza-dmsc-atn-agent-trust-negotiation] defines a pre-negotiation trust handshake that binds a capability manifest, a delegation chain, a provenance attestation, and a session receipt to a discovered agent identity, and computes an agreed scope through a specified intersection algebra over the peers' declarations. That work establishes what a pair of agents is permitted to attempt before a negotiation of terms opens. This document defines the evidence produced after such a negotiation closes, and it carries no capability manifest, no delegation chain, and no scope algebra of its own.¶

[I-D.wadkins-agentproto-action-determinability] states mechanism-independent requirements for establishing at a later time that a claimed action occurred under the conditions said to govern it, including that the governing conditions were fixed no later than the decision and that an independent evaluator can establish the claim without cooperation from an original participant. Those requirements are stated over any evidence format and define none. An attestation defined by this document is one artifact such an evaluator can read. Section 3.2 records that this document binds what the parties agreed at conclusion rather than a commitment fixed in advance, Section 14.3 records that it places no obligation on a policy evaluator, and Section 11.1 records what it does and does not establish about ordering.¶

[I-D.sergeev-claim-boundaries] states protocol-neutral limits on what signed evidence can support, and the bounds in Section 11.1 and Section 11.4 of this document correspond to rules 1, 2, 3, 4, and 8 of its Section 6: a verified attestation supports the claim stated in Section 1 under the key-binding premise of Section 11.4, and supports no claim about the truth of the outcome, the completeness of the transcript, or the order in which the transcript's messages were created.¶

[I-D.bradleyb-audit-decision-records] records authorization decisions rather than actions, so that a denial, an expiry, or an unfulfilled commitment remains representable, and it requires a record to disclose what establishes the order of the decision against the effect and whether that mechanism sits inside the producer's own trust boundary. This document records a digest and count that the parties countersigned, and Section 11.1 states what it does and does not establish about precedence.¶

[I-D.schrock-ep-bounded-capability-receipts] defines a signed capability carrying a budget with explicit units, together with a reserve, admit, and reconcile state machine that refuses overspend, prevents replay of an operation, serializes concurrent owners, and charges an indeterminate operation conservatively. It bounds how much authority an agent may consume before and while it acts. This document reports what a set of parties bound after a negotiation concluded, and it defines no budget, no reservation, no consumption record, and no single-use semantics of its own beyond the relying-side bound in Section 8.4.¶

[I-D.correctover-ccs] defines a runtime conformance check over an individual agent tool call across seven dimensions and emits a signed receipt carrying an allow, deny, or escalate verdict for one invocation, using Ed25519 signatures over JCS canonical JSON as this document does. It judges a single call at the moment that call is made and records one issuer's verdict. This document binds an outcome that several parties reached across many messages and records no verdict, so a deployment can produce both artifacts for one broader transaction without either standing in for the other.¶