eriknewton@gmail.com

Applications and Real-Time Autonomous agents can exchange offers and signatures without producing an artifact that records which parties reached which outcome, over which transcript digest and message count, and for how long that record may be relied upon. This document defines JSON agreement-evidence objects for structured, multi-attribute negotiation. The core object is an agreement attestation. A verified attestation establishes one thing: that a named set of parties jointly countersigned a stated outcome over a stated transcript digest and message count, together with behavioral counters each of them accepted. It does not establish that the outcome matches what the transcript says, that any statement a party made is true, or that the parties are anonymous. The format provides no member for a negotiated price, quantity, date, or principal identity. A producer is obligated not to place those values in the free-text members the format does provide, and a verifier cannot detect a violation of that obligation, so the absence of term values from a received object is a producer's obligation rather than a verified property. Sections 4 through 8 and 10 define every member of the object, its JSON type, its encoding, its value constraints, and the verification procedure. This document also defines relying-side freshness obligations and describes related approval, fulfillment, and revocation artifacts, whose formats it leaves to other documents. This document does not define identity, authority delegation, payment, settlement, transport, boundary-decision receipts, or a general evidence composition and sufficiency model.

Introduction A signature proves who signed particular bytes. It does not necessarily prove that two parties agreed or that a once-valid claim remains current. Single-issuer action receipts are useful evidence of what one policy engine, gateway, or observer recorded. They do not express a negotiated outcome that multiple counterparties jointly bind. This document occupies that narrower agreement-evidence layer. Negotiating parties exchange individually signed and hash-chained messages. At session conclusion, they produce an agreement attestation whose members are defined in . Every listed party countersigns the same issuance snapshot before the outcome can be credited as outcome-bound. The snapshot includes a transcript digest and message count that the parties countersigned. Its descriptive members are constrained so that behavioral evidence can be shared without disclosing the deal terms themselves. Verifying the object requires the object itself and a key-binding mechanism the deployment supplies. It does not require a particular transport, payment rail, transparency service, or cross-format composition framework. Transcript reconstruction is out of scope for this revision and may be specified in a later one. What a verified attestation establishes is stated exactly: a named set of parties jointly countersigned one stated outcome over one stated transcript digest and message count, with behavioral counters each of them accepted. This document defines no procedure for re-deriving the outcome from the transcript, so a verified attestation is no evidence that the outcome matches the transcript. It is no evidence that a statement a party made is true. It offers no anonymity: the agent identifier of every listed party is in the object, and a holder of two attestations can correlate them.

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.

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.

Terminology

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

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 , 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 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 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.

Agreement Formation and Evidence Surfaces

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 for how this scope choice relates to ongoing work in the broader agent-protocol space.

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 . 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 .

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 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 , and this document does not define one.

Agreement Attestation

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 ;
• 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. 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.

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 . Those values describe the session; they do not expose the negotiated terms.

Behavioral Signals Each parties[] element carries a behavior object holding the members defined in : 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.

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 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 signature of , encoded with the base64url alphabet of 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 . No member defined by this document carries a public key.
• A timestamp is an RFC 3339 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 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 . 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 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 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. Attestation Root Members

Member	Type	Cardinality	Constraints
concordia_attestation	string	required	Three dot-separated non-negative decimal integers, no leading zeros. "0.6.0" for this version.
attestation_id	string	required	1 to 256 octets, no whitespace.
session_id	string	required	1 to 256 octets, no whitespace.
timestamp	string	required	RFC 3339 date-time with a "Z" offset.
outcome	object	required	Members of Table 2. No other member.
parties	array	required	2 to 64 elements, each as in Table 3. Identifiers distinct per Section 6.2.
meta	object	required	Members of Table 5. No other member.
transcript_hash	string	required	"sha256:" plus 64 lowercase hexadecimal characters.
chain_head	string	required at 0.5.0 and later	"sha256:" plus 64 lowercase hexadecimal characters.
message_count	integer	required at 0.5.0 and later	1 to 10000 inclusive, per Section 11.7.
validity_temporal	object	required at 0.5.0 and later	Modes and semantics in Section 8.3.
countersignatures	object	required at 0.5.0 and later	Member names are exactly the agent identifiers in parties; values are signatures. Section 6.1.
summary	string	optional	At most 1024 Unicode scalar values. Constrained by Section 7.
references	array	optional	At most 32 elements, each as in Table 6.

Members of the outcome Object

Member	Type	Cardinality	Constraints
status	string	required	One of agreed, rejected, expired, withdrawn.
rounds	integer	required	0 to 2^53-1 inclusive.
duration_seconds	integer	required	0 to 2^53-1 inclusive.
terms_count	integer	optional	1 to 2^53-1 inclusive.
resolution_mechanism	string	optional	One of direct, split, foa, tradeoff, escalation, none.

Members of a parties Element

Member	Type	Cardinality	Constraints
agent_id	string	required	1 to 256 octets, no whitespace. Compared after normalization as stated above.
role	string	required	One of initiator, responder, mediator, witness.
behavior	object	required	Members of Table 4. No other member.
signature	string	required	Signature over that party's own behavioral record. See the note below this table.

A parties[] element's signature member is removed before the issuance snapshot is derived (). 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 specifies. Members of a behavior Object

Member	Type	Cardinality	Constraints
offers_made	integer	optional	0 to 2^53-1 inclusive.
concessions	integer	optional	0 to 2^53-1 inclusive.
concession_magnitude	number	optional	0.0 to 1.0 inclusive.
signals_shared	integer	optional	0 to 2^53-1 inclusive.
constraints_declared	integer	optional	0 to 2^53-1 inclusive.
constraints_violated	integer	optional	0 to 2^53-1 inclusive.
reasoning_provided	boolean	optional	true or false.
withdrawal	boolean	optional	true or false.
response_time_avg_seconds	number	optional	0 or greater.

Members of the meta Object

Member	Type	Cardinality	Constraints
category	string	optional	Taxonomy grammar below. At most 64 octets.
value_range	string	optional	Bucket vocabulary below. At most 32 octets.
extensions_used	array	optional	At most 16 elements, each a string of 1 to 64 octets with no whitespace naming a protocol extension active in the session.
mediator_invoked	boolean	optional	true or false.

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. Members of a references Element

Member	Type	Cardinality	Constraints
id	string	required	1 to 256 octets, no whitespace.
type	string	required	1 to 64 octets, no whitespace. Emit vocabulary below.
relationship	string	required	1 to 64 octets, no whitespace. Emit vocabulary below.
version	string	optional	At most 256 octets, no whitespace.
signed_at	string	optional	RFC 3339 date-time with a "Z" offset.
signer_did	string	optional	1 to 256 octets, no whitespace.

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 . The validity_temporal object carries a mode discriminator and the members that mode requires. 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.

Canonicalization and Signatures

Canonical JSON Objects defined by this document are JSON values that use the JSON Canonicalization Scheme (JCS) . A signer and verifier MUST canonicalize the same logical object to identical UTF-8 bytes before signing or verification. Implementations MUST reject values that cannot be represented under 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 and the bounds of , 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.

Signature Verification Criteria Implementations MUST verify Ed25519 signatures as specified in 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 . 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. states that bound.

Multi-Party Binding

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 and . 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 pins them. The member set of an attestation is closed: an attestation carries only the members defined in , at the root and at every nested object. Step 2 of therefore rejects an attestation carrying any member does not define, including a member named signature at a location does not define, before any signature is verified. The removal rule in this section operates on that closed set.

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 .

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 is rejected at step 2 of and is not retained. An artifact whose version is well formed and below 0.5.0 leaves the procedure of 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 applies to it, because every requirement there is defined for version 0.5.0 and later.

Privacy Requirements An attestation carries metadata about negotiation behavior. It does not disclose the deal. Items 1 through 4 below constrain the content an implementation places in free-form members, so they are producing-side obligations that a verifier cannot confirm by inspection, and the verification result vocabulary of carries no state for them: an attestation that violates one of them still verifies. An implementation that assembles an attestation:

1. MUST NOT populate any field with an exact negotiated price, quantity, date, or other term value;
2. MUST NOT include an item or service description beyond the permitted category and value_range fields;
3. MUST NOT include free-text reasoning copied from negotiation messages;
4. MUST NOT include the identity of a human or organization represented by an agent; only the agent identifier is carried;
5. MUST draw value_range, when present, from the fixed bucket vocabulary defined in and MUST reject all other values rather than coerce them;
6. MUST encode category, when present, as a dotted lowercase taxonomy path of at most 64 octets matching the grammar in , where each segment is one or more characters drawn from a to z, 0 to 9, underscore, and hyphen, and MUST reject any other value rather than coercing it;
7. MAY omit category for additional privacy;
8. MUST reject a reference identifier longer than 256 octets or containing whitespace, and MUST reject an attestation carrying more than 32 references, rather than truncating either; and
9. MUST keep summary, when present, within 1024 Unicode scalar values and MUST NOT copy a negotiated term value or free-text reasoning into it. summary is a free-text member, so this constraint is a producing-side obligation that a verifier cannot confirm by inspection, and it widens the residual channel described below.

The taxonomy grammar constrains shape rather than meaning. A dishonest party can encode its own term in a syntactically valid category segment, and it has wider latitude still in the free-text summary member. This is an accepted, bounded residual channel over category and summary together: it can expose that party's own information, and it does not let that party sign on behalf of a counterparty. A future registered taxonomy could narrow the category half of it.

Freshness and Replay

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 , 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 , 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.

Producing-Side Obligation A party MUST NOT countersign an attestation whose validity_temporal lifetime exceeds 90 days as defines that quantity. That lifetime is the length of the interval that 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.

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 date-time values encoded as 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 and 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 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.

Single Use An attestation defined by this document carries no single-use semantics, and the temporal validity of 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 .

Related Evidence Artifacts This section is informative. It describes related companion artifacts whose full normative definition belongs to a separate document. It states no requirement of its own and uses no requirement keyword. No requirement of this document reads a member of any artifact sketched here. The sketches are drawn from the Concordia Protocol Specification named in .

ApprovalReceipt An ApprovalReceipt records a human or policy approval decision over the digest of the canonical form of an Offer as defined in ; 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.

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.

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.

Verification Procedure To reach a terminal state for a received artifact, a relying party MUST perform the following steps in fail-closed order. The four terminal states are defined in , and step 9 exposes exactly one of them.

1. Reject the received bytes with the terminal state not-bound, without parsing them, if their length exceeds the relying party's maximum artifact size, which caps at 262144 octets.
2. Strictly parse the received bytes and reject the artifact with the terminal state not-bound if they are not I-JSON , if their JSON nesting depth exceeds 16, or if concordia_attestation is absent, does not match the grammar in , or is greater than the highest version this verifier implements. Then read that member. An artifact whose value is well formed and below 0.5.0 terminates here with the terminal state legacy, and the verifier MUST NOT apply any step below to it: it performs no signature verification, no outcome binding, no temporal check, and no revocation check over that artifact. For an artifact at version 0.5.0 or later, reject the artifact with the terminal state not-bound if any value is malformed under , if any member is not defined by , or if message_count lies outside 1 to 10000 inclusive. Every check in this step precedes every signature verification below.
3. Resolve, for every agent identifier in parties[], exactly one Ed25519 public key valid at the attestation's issuance time, using the key-binding mechanism the deployment profile defines. This document defines no such mechanism. If a key cannot be resolved, if more than one key resolves, or if the deployment defines no binding mechanism, the verifier terminates with the terminal state not-bound.
4. Recompute the countersignature payload and verify every listed party's countersignature as specified in . If any check there fails, terminate with the terminal state not-bound.
5. Reject the attestation unless the verifier's current time lies within the interval expressed by validity_temporal, and validate that interval's ordering, its lifetime against the relying party's maximum, and both the attestation timestamp and the interval start against the relying party's clock-skew allowance. Reject the attestation with the terminal state not-bound if any of those checks fails. Every artifact that reaches this step carries version 0.5.0 or later and therefore carries the member this step reads.
6. Apply the relying party's own freshness ceiling, even when it is tighter than the signed window, and reject the attestation with the terminal state not-bound when the ceiling is exceeded.
7. Determine revocation status. If the deployment profile names a revocation source, apply the records that source supplies as the deployment's own definition of that source specifies, and reject a revoked attestation with the terminal state not-bound. This document defines no revocation record format, no retrieval mechanism, and no authority model. The verifier MUST treat revocation status as undetermined in each of three cases: the deployment names no revocation source, the named source is unavailable, or the named source supplies a record that cannot be interpreted under the deployment's own definition of that source. In every one of those three cases the verifier MUST NOT report the artifact as current and MUST carry it to step 9 as bound-only, which retains the outcome-binding property the earlier steps established.
8. Compare session_id and the agent identifiers in parties[] against the session and counterparty set the relying party expected for this interaction, and reject the attestation with the terminal state not-bound when either differs. A verified attestation is evidence about the session it names and about no other.
9. Only then expose one terminal state to application policy: current when step 7 determined revocation status and the artifact is not revoked, and bound-only otherwise. An artifact that reached this step is outcome-bound.

The version gate at step 2 is what keeps the legacy state coherent. An artifact below 0.5.0 carries no signer-asserted validity window and, on the 0.5.0 line, carries no countersignature map, so running a later step over it would ask for a member it does not carry. An artifact whose version string is malformed is rejected at step 2 with the terminal state not-bound and is not retained as legacy. The four terminal states are the whole reported vocabulary. An implementation MAY expose diagnostic detail alongside the state it reports, and MUST NOT report any other state name in its place. An implementation MUST NOT silently replace one terminal state with another, and in particular MUST NOT report a legacy or bound-only artifact as current. A verifier that returns a typed failure reason MUST distinguish a result this document's checks cannot produce at all from a result this verifier could not reach with the inputs it held, and MUST NOT report the second as the first. This document defines no scope comparison, so a scope relation falls in the first category, while an unresolvable party key or an unavailable revocation source falls in the second.

Security Considerations This section is written against four attacker positions: an on-path attacker that can read, delay, suppress, or modify messages in transit; a single dishonest party to the negotiation; the complete listed party set acting together against a third party; and an attacker holding a compromised party key. What the checks preserve against each position, and what they leave open, is stated here rather than left to the reader. Against the on-path attacker, signature verification detects modification of the countersigned attestation bytes, and no check detects delay, suppression, or traffic analysis (). Against a single dishonest party, requiring every listed party's countersignature preserves the jointly bound members against unilateral rewriting, and no check makes that party's behavioral self-report objective or closes the residual channel over category and summary that records (). Against an attacker holding a compromised party key, revocation bounds how long such an artifact remains useful once the deployment detects the compromise and the verifier can reach a revocation source. No check detects an artifact that back-dates its own timestamp and validity_temporal members, so revocation bounds this attacker rather than detecting it (). Collusion of the entire listed party set against a third party is the design's primary residual risk, and no check defined here detects it.

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 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.

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.

Privacy Leakage The closed schema provides no member for a raw deal term. The residual channel described in 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.

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 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 . 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 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.

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.

Post-Quantum Migration Path Ed25519 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. (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 ), 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. 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.

Resource Limits The limits of this section are relying-party requirements, and 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 , which are the artifact-size cap, the nesting-depth cap, and the message_count range, run before any signature verification. The member caps of 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.

Operational and Privacy Considerations Implementations SHOULD keep raw transcripts under the parties' control and present the narrower attestation when term disclosure is unnecessary. Logs and diagnostics SHOULD avoid copying raw deal terms or cryptographic material. Verifiers SHOULD return typed failure reasons without echoing untrusted private content, on the terms stated in . Clock synchronization is operationally important; the finite skew bound a verifier enforces is specified in .

IANA Considerations This document requests no IANA actions. The vocabularies it defines, the outcome status values of , the value_range buckets and category grammar of , and the reference type and relationship values of , are versioned within this document's own member set and change only by publication of a new version. A recipient rejects a status or value_range value outside the enumerated set, and preserves an unrecognized reference type or relationship value as an opaque string. This document registers no media type. An attestation defined here is carried inside a deployment's own protocol, which names the type it uses, and this document defines no transport. A version that defines a transport is where a media-type registration belongs.

Relationship to Neighboring Work This section is informative.

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 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 or from whatever document a deployment names, and no requirement of this document reads a member of any of them. The verification procedure () 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. illustrates one such external composition model without creating a dependency on it.

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.

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.

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.

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

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.

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.

Adjacent Multi-Signer Evidence Work Other individual Internet-Drafts define multi-signer evidence for agent actions and transactions. 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. 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 (); it structurally excludes negotiated price, quantity, date, and free-text term values from the signed object (); and it defines an independent relying-side freshness obligation () 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.

Adjacent Requirements and Single-Issuer Evidence Work 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. 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. records that this document binds what the parties agreed at conclusion rather than a commitment fixed in advance, records that it places no obligation on a policy evaluator, and records what it does and does not establish about ordering. states protocol-neutral limits on what signed evidence can support, and the bounds in and of this document correspond to rules 1, 2, 3, 4, and 8 of its Section 6: a verified attestation supports the claim stated in under the key-binding premise of , 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. 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 states what it does and does not establish about precedence. 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 . 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.

Normative References Informational. Cited normatively for the Ed25519 signature algorithm and the verification criteria required by ; as with , , and , this is a downward reference from a Standards Track document and is expected to be flagged and pre-approved at IETF Last Call. Informational. Cited normatively for the canonicalization scheme used throughout this document; a Standards Track document citing an Informational RFC normatively is a downward reference and is expected to be flagged and pre-approved at IETF Last Call. Two verified errata are on file against this RFC and were checked at conversion time: Errata ID 6292 (editorial, Section 3.2.2.2 cross reference) and Errata ID 7920 (technical, Section 5, handling of negative zero); neither changes the normative text this document relies on. Informational. Cited normatively for the SHA-256 digest strings chain_head and transcript_hash; as with , , and , this is a downward reference from a Standards Track document and is expected to be flagged and pre-approved at IETF Last Call. Informational. Cited normatively for the I-JSON restrictions applied at step 2 of ; as with , , and , this is a downward reference from a Standards Track document and is expected to be flagged and pre-approved at IETF Last Call. The Unicode Consortium Informative References Informational. Title, author list, and June 2026 publication date verified at the RFC Editor and the datatracker on 2026-09-16. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-10-03. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-10-03; this is the document that carries the EP-AEC sufficiency and composition model referenced informatively in , distinct from its sibling , which defines a budgeted capability. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. Work in progress. Revision, date, title, and author verified against the IETF archive on 2026-09-24. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16; the author field at the datatracker renders as "Bradley B" and is cited here as it appears there. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16.

Source Crosswalk This appendix is informative. The source specification is the Concordia Protocol Specification, the document from which this document's artifact family is drawn. The table records which section of that specification each subject of this document is derived from, for editor traceability; it is not part of the normative text, and no requirement of this document depends on it. Crosswalk to the Source Specification

Document subject	Concordia Protocol Specification section
Scope and non-goals	Sections 1.4 and 2
Terms and agreement surfaces	Sections 3 and 4
Lifecycle and offer grammar	Sections 5 and 6
JCS, signatures, and transcript digest fields	Sections 9.2, 9.3, and 9.6.2
Attestation schema and fields	Sections 9.6.2 and 9.6.3
Approval, fulfillment, revocation	Sections 9.6.4a through 9.6.4d
Outcome binding	Section 9.6.5a
Privacy invariant	Section 9.6.6
Freshness and replay	Section 9.7
Threat-model security organization	Section 9.8
Typed references	Section 11.5

Implementation Status This appendix is informative and is provided in the form described by . The RFC Editor is requested to remove this appendix before publication, along with the reference to . The implementations reported on are a JSON Schema for the attestation, a Python reference SDK, a JavaScript reference SDK, and a conformance suite, all maintained by the author of this document. Every row below describes one source tree at one revision: the Concordia repository on its main branch at commit 847729cd. It does not describe a package published to an index, and a published package may be older or newer than that commit. At that commit the attestation version the implementations emit is 0.5.0. The version this document specifies is 0.6.0, and no part of that line exists at that commit. The table is generated rather than edited. It carries 62 rows, one for every requirement-keyword occurrence in Sections 4 through 10 of this document, in document order: 35 occurrences of MUST, 18 of MUST NOT, 7 of MAY, 1 of REQUIRED, and 1 of SHOULD. A requirement inside that range cannot be omitted by an editorial choice. The range is not the whole document: and carry requirement keywords that this table does not enumerate, among them the resource limits of that steps 1 and 2 of apply. Each row carries exactly one of three states, and the state follows a rule rather than a judgement, so that two rows reporting the same fact carry the same state:

• "implemented at 847729cd" means the behavior the requirement describes is present at that commit. Every such row carries an evidence key naming the test file or the schema construct that shows it; the keys are listed after the table. A row granting a permission is reported by whether the tree at that commit behaves consistently with the permission. The row reports that one requirement and says nothing about the constraints this document adds elsewhere.
• "scheduled for 0.6.0" means the requirement addresses a verifier, a relying party, or a producer, the implementations could carry it, and they do not carry it at that commit. It states this document's target and claims no existing code.
• "specified here, no implementation" means the requirement addresses producer free-text content where no validator can test compliance. No revision of these implementations moves such a row.

The table contains 17 rows implemented at 847729cd, 40 rows scheduled for 0.6.0, and 5 rows specified here with no implementation. The implementations emit 0.5.0 and this document specifies 0.6.0. Per-Requirement Implementation Status

Requirement	Section	Status
A relying party MAY calculate its own score from the behavioral signals or ignore them	4.3	implemented at 847729cd [E1]
The four unused bits of the final encoded signature group MUST be zero	4.4	scheduled for 0.6.0
A recipient MUST reject a signature value of the wrong length, with absent or misplaced padding, with a character outside the alphabet, with whitespace, or with non-zero unused bits	4.4	scheduled for 0.6.0
A recipient MUST compare decoded signature octets rather than encoded characters	4.4	scheduled for 0.6.0
A recipient MUST reject a timestamp whose offset is not the single character Z	4.4	scheduled for 0.6.0
A recipient MUST reject a fractional second of more than three digits	4.4	scheduled for 0.6.0
A recipient MUST reject a string member that is not in Normalization Form C	4.4	scheduled for 0.6.0
A recipient MUST compare identifier strings only after normalization	4.4	scheduled for 0.6.0
A member declared free of whitespace MUST NOT carry a White_Space character	4.4	scheduled for 0.6.0
Such a member MUST NOT carry a character in the listed control and format ranges	4.4	scheduled for 0.6.0
A recipient MUST preserve an unrecognized reference type or relationship as an opaque string	4.4	implemented at 847729cd [E2]
A verifier MUST NOT treat a parties element signature as evidence that an outcome is outcome-bound	4.4	scheduled for 0.6.0
A recipient MUST reject a value_range outside the enumerated bucket vocabulary	4.4	implemented at 847729cd [E3]
A signer and a verifier MUST canonicalize the same logical object to identical UTF-8 bytes	5.1	implemented at 847729cd [E4]
Implementations MUST reject values that cannot be represented under Section 4.4 and the canonicalization rules	5.1	scheduled for 0.6.0
A recipient MUST reject a numeric value outside its stated range	5.1	scheduled for 0.6.0
A recipient MUST reject an object carrying a repeated member name, detected at parse time	5.1	scheduled for 0.6.0
A recipient MUST reject input that is not well-formed UTF-8 or that carries an unpaired surrogate	5.1	scheduled for 0.6.0
Implementations MUST verify Ed25519 signatures with the cofactorless equation of RFC 8032	5.2	scheduled for 0.6.0
Implementations MUST reject a non-canonical R or S, an unreduced S, or a public key not of order L	5.2	scheduled for 0.6.0
An implementation MUST derive the countersignature payload by the four steps of this section	6.1	implemented at 847729cd [E5]
A verifier MUST NOT credit an outcome as outcome-bound unless all seven listed conditions hold	6.2	scheduled for 0.6.0
A well-formed artifact below 0.5.0 MAY be retained as a record of its own contents	6.2	implemented at 847729cd [E6]
Its outcome MUST NOT be credited as outcome-bound	6.2	scheduled for 0.6.0
It MUST NOT be reported as current	6.2	scheduled for 0.6.0
An assembling implementation MUST NOT populate any member with an exact negotiated term value	7	specified here, no implementation
It MUST NOT include an item or service description beyond category and value_range	7	specified here, no implementation
It MUST NOT include free-text reasoning copied from negotiation messages	7	specified here, no implementation
It MUST NOT include the identity of a represented human or organization	7	specified here, no implementation
It MUST draw value_range from the fixed bucket vocabulary	7	implemented at 847729cd [E3]
It MUST reject every other value_range value rather than coerce it	7	implemented at 847729cd [E3]
It MUST encode category to the dotted lowercase taxonomy grammar	7	implemented at 847729cd [E3]
It MUST reject every other category value rather than coercing it	7	implemented at 847729cd [E3]
It MAY omit category for additional privacy	7	implemented at 847729cd [E7]
It MUST reject a reference identifier longer than 256 octets or carrying whitespace	7	implemented at 847729cd [E3]
It MUST reject an attestation carrying more than 32 references	7	implemented at 847729cd [E3]
It MUST keep summary within 1024 Unicode scalar values	7	scheduled for 0.6.0
It MUST NOT copy a negotiated term value or free-text reasoning into summary	7	specified here, no implementation
A relying party MUST configure a maximum evidence age, a maximum validity lifetime, and a skew allowance within the stated ceilings	8.1	scheduled for 0.6.0
A relying party MUST reject evidence exceeding any of those three	8.1	scheduled for 0.6.0
A relying party MAY configure tighter values	8.1	scheduled for 0.6.0
A relying party MUST enforce its own evidence age independently of the signed window	8.1	scheduled for 0.6.0
A relying party MUST reject a timestamp or interval start future-dated beyond the skew allowance	8.1	scheduled for 0.6.0
A verifier MUST enforce the finite skew bound and fail closed outside it	8.1	scheduled for 0.6.0
A relying party MUST reject an attestation whose validity interval has ended	8.1	implemented at 847729cd [E6]
A relying party MAY apply a tighter freshness bound than the signer asserted	8.1	scheduled for 0.6.0
A party MUST NOT countersign a validity lifetime exceeding 90 days	8.2	implemented at 847729cd [E6]
A party MAY apply a shorter maximum lifetime	8.2	implemented at 847729cd [E6]
validity_temporal is REQUIRED on every attestation at 0.5.0 and later	8.3	implemented at 847729cd [E8]
A verifier MUST reject a validity_temporal object that is malformed, carries an extra member, or expresses an empty or reversed interval	8.3	scheduled for 0.6.0
A relying party SHOULD keep a consumption record for an attestation it acts on, keyed by attestation_id	8.4	scheduled for 0.6.0
A relying party MUST perform the nine verification steps in fail-closed order	10	scheduled for 0.6.0
An artifact below 0.5.0 terminates at step 2 with the terminal state legacy, and the verifier MUST NOT apply any later step to it	10	scheduled for 0.6.0
The verifier MUST treat revocation status as undetermined in each of the three named cases	10	scheduled for 0.6.0
In each of those cases the verifier MUST NOT report the artifact as current	10	scheduled for 0.6.0
In each of those cases the verifier MUST carry the artifact to step 9 as bound-only	10	scheduled for 0.6.0
An implementation MAY expose diagnostic detail alongside the terminal state it reports	10	scheduled for 0.6.0
An implementation MUST NOT report any state name other than the four terminal states	10	scheduled for 0.6.0
An implementation MUST NOT silently replace one terminal state with another	10	scheduled for 0.6.0
An implementation MUST NOT report a legacy or bound-only artifact as current	10	scheduled for 0.6.0
A typed failure reason MUST distinguish a result the checks cannot produce from one this verifier could not reach	10	scheduled for 0.6.0
A typed failure reason MUST NOT report the second of those as the first	10	scheduled for 0.6.0

Evidence keys for the rows above, each a path in the Concordia repository at commit 847729cd:

E1:

concordia/reputation/scorer.py, which computes scores outside the attestation.

E2:

tests/test_references.py, the unknown-type and unknown-relationship round-trip cases.

E3:

tests/test_attestation_l3_bucket_vocabulary.py, which pins the enumerated value_range vocabulary, the category grammar, the reference string caps, and the 32-reference count cap, each rejected rather than coerced.

E4:

tests/test_canonicalization_rfc8785.py.

E5:

tests/test_attestation_signature_verification.py, against concordia/attestation.py and concordia/cosign.py, which strip every signature member, exclude the countersignature map, and canonicalize.

E6:

tests/test_validity_temporal.py, including the ended-interval case, the legacy-readable case, the issuer refusal above 90 days, and the shorter-window cases.

E7:

schemas/attestation.schema.json, where the meta object carries no required member, so category may be omitted.

E8:

schemas/attestation.schema.json, the version-gated allOf that requires validity_temporal at 0.5.0 and later.

Two notes. First, this document removes members that the schema at that commit carries: the fulfillment member of the attestation root, the extensions member of a reference element, and the window validity mode. It also removes the requirements that read members of the approval, fulfillment, and revocation artifacts, since it does not define those artifacts. An artifact at version 0.5.0 or later carrying a removed member is rejected at step 2 of , which is intended. A second note bears on the legacy rows. At 847729cd the temporal validity helper returns a valid result for an artifact below 0.5.0 that carries no validity window, so that commit does not implement the rule that such an artifact is never reported as current. The two rows carrying that rule read as scheduled for that reason. This appendix is evidence for draft readiness. It is not a normative dependency on either reference SDK.

EP-AEC Compatibility This appendix is informative and creates no normative dependency. , also known by its short name EP-AEC, defines a transport-agnostic composition object and a fail-closed evaluation algorithm for combining heterogeneous agent-action evidence against a relying party's pinned evidence requirement. It distinguishes whether a set of evidence is SATISFIED (it fills the stated requirement) from whether an action is AUTHORIZED (a separate, local policy decision), and states that native validity alone is not sufficient for composition. An attestation at version 0.6.0 that reaches the terminal state current under of this document is a candidate native evidence component under that model: an EP-AEC composition layer could treat this document's own countersignature and freshness semantics as native validity inputs, while still applying its own requirement-level freshness bound. This document carries no artifact signature distinct from the party countersignatures (), and it determines revocation status only when the deployment supplies a revocation source (). This document does not require, normatively reference, or depend on EP-AEC or any other evidence-composition framework. An implementation of this document's attestation format and verification procedure ( and ) is complete and independently useful without it.