Network Working Group E. Newton Internet-Draft 3 October 2026 Intended status: Standards Track Expires: 6 April 2027 Agreement Evidence for Multi-Party Agent Negotiation draft-newton-agreement-evidence-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Newton Expires 6 April 2027 [Page 1] Internet-Draft Agreement Evidence October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Agreement Formation and Evidence Surfaces . . . . . . . . . . 7 3.1. Negotiation Lifecycle . . . . . . . . . . . . . . . . . . 7 3.2. Two Evidence Surfaces . . . . . . . . . . . . . . . . . . 7 4. Agreement Attestation . . . . . . . . . . . . . . . . . . . . 8 4.1. Attestation Members . . . . . . . . . . . . . . . . . . . 8 4.2. Outcome Vocabulary . . . . . . . . . . . . . . . . . . . 9 4.3. Behavioral Signals . . . . . . . . . . . . . . . . . . . 9 4.4. Field Definitions . . . . . . . . . . . . . . . . . . . . 9 5. Canonicalization and Signatures . . . . . . . . . . . . . . . 16 5.1. Canonical JSON . . . . . . . . . . . . . . . . . . . . . 17 5.2. Signature Verification Criteria . . . . . . . . . . . . . 17 6. Multi-Party Binding . . . . . . . . . . . . . . . . . . . . . 17 6.1. Countersignature Payload . . . . . . . . . . . . . . . . 17 6.2. Outcome-Binding Verification . . . . . . . . . . . . . . 18 7. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 19 8. Freshness and Replay . . . . . . . . . . . . . . . . . . . . 20 8.1. General Relying-Side Obligation . . . . . . . . . . . . . 20 8.2. Producing-Side Obligation . . . . . . . . . . . . . . . . 21 8.3. Required Temporal Validity . . . . . . . . . . . . . . . 21 Newton Expires 6 April 2027 [Page 2] Internet-Draft Agreement Evidence October 2026 8.4. Single Use . . . . . . . . . . . . . . . . . . . . . . . 22 9. Related Evidence Artifacts . . . . . . . . . . . . . . . . . 22 9.1. ApprovalReceipt . . . . . . . . . . . . . . . . . . . . . 22 9.2. FulfillmentAttestation . . . . . . . . . . . . . . . . . 23 9.3. RevocationRecord and Cascade Decision . . . . . . . . . . 23 10. Verification Procedure . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11.1. Dishonest Negotiation Party . . . . . . . . . . . . . . 26 11.2. Compromised Delivery Path . . . . . . . . . . . . . . . 27 11.3. Privacy Leakage . . . . . . . . . . . . . . . . . . . . 27 11.4. Key Compromise and Identity . . . . . . . . . . . . . . 27 11.5. Sybil Behavior and Completeness . . . . . . . . . . . . 28 11.6. Post-Quantum Migration Path . . . . . . . . . . . . . . 28 11.7. Resource Limits . . . . . . . . . . . . . . . . . . . . 29 12. Operational and Privacy Considerations . . . . . . . . . . . 29 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 14. Relationship to Neighboring Work . . . . . . . . . . . . . . 30 14.1. Evidence Composition and Sufficiency . . . . . . . . . . 30 14.2. Evidence Request and Refusal . . . . . . . . . . . . . . 30 14.3. Authority and Mandates . . . . . . . . . . . . . . . . . 31 14.4. Boundary-Decision and Action Receipts . . . . . . . . . 31 14.5. Settlement Evidence . . . . . . . . . . . . . . . . . . 31 14.6. Relationship to the agentproto Working Group . . . . . . 31 14.7. Relationship to a Neutral Evidence-Composition Interface . . . . . . . . . . . . . . . . . . . . . . . 32 14.8. Adjacent Multi-Signer Evidence Work . . . . . . . . . . 32 14.9. Adjacent Requirements and Single-Issuer Evidence Work . 33 15. Normative References . . . . . . . . . . . . . . . . . . . . 34 16. Informative References . . . . . . . . . . . . . . . . . . . 35 Appendix A. Source Crosswalk . . . . . . . . . . . . . . . . . . 38 Appendix B. Implementation Status . . . . . . . . . . . . . . . 39 Appendix C. EP-AEC Compatibility . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 1. 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 Section 4.4. Every listed party countersigns the same issuance snapshot before the outcome can Newton Expires 6 April 2027 [Page 3] Internet-Draft Agreement Evidence October 2026 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. 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; Newton Expires 6 April 2027 [Page 4] Internet-Draft Agreement Evidence October 2026 * 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. Terminology 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. Newton Expires 6 April 2027 [Page 5] Internet-Draft Agreement Evidence October 2026 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. Newton Expires 6 April 2027 [Page 6] Internet-Draft Agreement Evidence October 2026 3. Agreement Formation and Evidence Surfaces 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 Newton Expires 6 April 2027 [Page 7] Internet-Draft Agreement Evidence October 2026 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. Agreement Attestation 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. Newton Expires 6 April 2027 [Page 8] Internet-Draft Agreement Evidence October 2026 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. Newton Expires 6 April 2027 [Page 9] Internet-Draft Agreement Evidence October 2026 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. Newton Expires 6 April 2027 [Page 10] Internet-Draft Agreement Evidence October 2026 * 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. +=======================+=========+=============+==================+ | 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 | Newton Expires 6 April 2027 [Page 11] Internet-Draft Agreement Evidence October 2026 | | | | 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 | "sha256:" plus | | | | 0.5.0 and | 64 lowercase | | | | later | hexadecimal | | | | | characters. | +-----------------------+---------+-------------+------------------+ | message_count | integer | required at | 1 to 10000 | | | | 0.5.0 and | inclusive, per | | | | later | Section 11.7. | +-----------------------+---------+-------------+------------------+ | validity_temporal | object | required at | Modes and | | | | 0.5.0 and | semantics in | | | | later | Section 8.3. | +-----------------------+---------+-------------+------------------+ | countersignatures | object | required at | Member names are | | | | 0.5.0 and | exactly the | | | | later | 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. | +-----------------------+---------+-------------+------------------+ Table 1: Attestation Root Members Newton Expires 6 April 2027 [Page 12] Internet-Draft Agreement Evidence October 2026 +======================+=========+=============+====================+ | 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. | +----------------------+---------+-------------+--------------------+ Table 2: Members of the outcome Object +===========+========+=============+================================+ | 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. | +-----------+--------+-------------+--------------------------------+ Table 3: Members of a parties Element Newton Expires 6 April 2027 [Page 13] Internet-Draft Agreement Evidence October 2026 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. +===========================+=========+=============+=============+ | 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. | +---------------------------+---------+-------------+-------------+ Table 4: Members of a behavior Object Newton Expires 6 April 2027 [Page 14] Internet-Draft Agreement Evidence October 2026 +==================+=========+=============+========================+ | 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. | +------------------+---------+-------------+------------------------+ Table 5: Members of the meta Object 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. Newton Expires 6 April 2027 [Page 15] Internet-Draft Agreement Evidence October 2026 +==============+========+=============+====================+ | 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. | +--------------+--------+-------------+--------------------+ Table 6: Members of a references Element 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. Canonicalization and Signatures Newton Expires 6 April 2027 [Page 16] Internet-Draft Agreement Evidence October 2026 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. Multi-Party Binding 6.1. Countersignature Payload The countersignature payload is the JCS canonicalization of the issuance snapshot. To derive it, an implementation MUST: Newton Expires 6 April 2027 [Page 17] Internet-Draft Agreement Evidence October 2026 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. Newton Expires 6 April 2027 [Page 18] Internet-Draft Agreement Evidence October 2026 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. 7. 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 Section 2.2 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 Section 4.4 and MUST reject all other values rather than coerce them; Newton Expires 6 April 2027 [Page 19] Internet-Draft Agreement Evidence October 2026 6. MUST encode category, when present, as a dotted lowercase taxonomy path of at most 64 octets matching the grammar in Section 4.4, 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. 8. Freshness and Replay 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. Newton Expires 6 April 2027 [Page 20] Internet-Draft Agreement Evidence October 2026 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 Newton Expires 6 April 2027 [Page 21] Internet-Draft Agreement Evidence October 2026 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. 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 Appendix A. 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. Newton Expires 6 April 2027 [Page 22] Internet-Draft Agreement Evidence October 2026 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. 10. 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 Section 2.2, 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 Section 11.7 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 [RFC7493], if their JSON nesting depth exceeds 16, or if concordia_attestation is absent, does not match the grammar in Section 4.4, 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 Section 4.4, if any member is not defined by Section 4.4, or if message_count lies outside 1 to 10000 inclusive. Every check in this step precedes every signature verification below. Newton Expires 6 April 2027 [Page 23] Internet-Draft Agreement Evidence October 2026 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 Section 6.2. 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. Newton Expires 6 April 2027 [Page 24] Internet-Draft Agreement Evidence October 2026 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. 11. 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 (Section 11.2). 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 Section 7 records (Section 11.1). Newton Expires 6 April 2027 [Page 25] Internet-Draft Agreement Evidence October 2026 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 (Section 11.4). 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. 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. Newton Expires 6 April 2027 [Page 26] Internet-Draft Agreement Evidence October 2026 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 Newton Expires 6 April 2027 [Page 27] Internet-Draft Agreement Evidence October 2026 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- Newton Expires 6 April 2027 [Page 28] Internet-Draft Agreement Evidence October 2026 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. 12. 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 Section 10. Clock synchronization is operationally important; the finite skew bound a verifier enforces is specified in Section 8.1. Newton Expires 6 April 2027 [Page 29] Internet-Draft Agreement Evidence October 2026 13. IANA Considerations This document requests no IANA actions. The vocabularies it defines, the outcome status values of Section 4.2, the value_range buckets and category grammar of Section 4.4, and the reference type and relationship values of Section 4.4, 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. 14. Relationship to Neighboring Work This section is informative. 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- Newton Expires 6 April 2027 [Page 30] Internet-Draft Agreement Evidence October 2026 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." Newton Expires 6 April 2027 [Page 31] Internet-Draft Agreement Evidence October 2026 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. Newton Expires 6 April 2027 [Page 32] Internet-Draft Agreement Evidence October 2026 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, Newton Expires 6 April 2027 [Page 33] Internet-Draft Agreement Evidence October 2026 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. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . Informational. Cited normatively for the SHA-256 digest strings chain_head and transcript_hash; as with [RFC8785], [RFC8032], and [RFC7493], this is a downward reference from a Standards Track document and is expected to be flagged and pre-approved at IETF Last Call. Newton Expires 6 April 2027 [Page 34] Internet-Draft Agreement Evidence October 2026 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . Informational. Cited normatively for the I-JSON restrictions applied at step 2 of Section 10; as with [RFC8785], [RFC8032], and [RFC6234], this is a downward reference from a Standards Track document and is expected to be flagged and pre- approved at IETF Last Call. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . Informational. Cited normatively for the Ed25519 signature algorithm and the verification criteria required by Section 5.2; as with [RFC8785], [RFC6234], and [RFC7493], this is a downward reference from a Standards Track document and is expected to be flagged and pre-approved at IETF Last Call. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 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. [UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", . 16. Informative References Newton Expires 6 April 2027 [Page 35] Internet-Draft Agreement Evidence October 2026 [I-D.bradleyb-audit-decision-records] B, B., "Signed Decision Records for Agent Authorization: Disclosures, Entry Emission, and Ordering Evidence", Work in Progress, Internet-Draft, draft-bradleyb-audit- decision-records-00, 13 August 2026, . 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. [I-D.correctover-ccs] Wang, G., "Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls", Work in Progress, Internet-Draft, draft-correctover-ccs-09, 14 September 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. [I-D.laxsharma-pact] Sharma, L., "PACT: Co-Signed Task Contracts, Delivery and Verdict Records, and Outcome Records for Autonomous Agents", Work in Progress, Internet-Draft, draft- laxsharma-pact-02, 16 September 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-10-03. [I-D.mih-agent-bilateral-attestation] Mih, S., "Bilateral Attestation of Cross-Organization Agent Actions", Work in Progress, Internet-Draft, draft- mih-agent-bilateral-attestation-02, 13 September 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. [I-D.schrock-ep-authorization-evidence-chain] Schrock, I., "Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)", Work in Progress, Internet-Draft, draft-schrock-ep-authorization- evidence-chain-07, 28 September 2026, . 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 Newton Expires 6 April 2027 [Page 36] Internet-Draft Agreement Evidence October 2026 referenced informatively in Appendix C, distinct from its sibling [I-D.schrock-ep-bounded-capability-receipts], which defines a budgeted capability. [I-D.schrock-ep-bounded-capability-receipts] Schrock, I., "Bounded Capability Receipts and Durable Spend Control for Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-bounded-capability- receipts-06, 9 September 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. [I-D.sergeev-claim-boundaries] Sergeev, M., "Claim Boundaries for Execution Evidence", Work in Progress, Internet-Draft, draft-sergeev-claim- boundaries-01, 23 September 2026, . Work in progress. Revision, date, title, and author verified against the IETF archive on 2026-09-24. [I-D.somoza-dmsc-atn-agent-trust-negotiation] Somoza, E., "Agent Trust Negotiation: Capability, Delegation, and Provenance Binding for AI Agents", Work in Progress, Internet-Draft, draft-somoza-dmsc-atn-agent- trust-negotiation-00, 29 May 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. [I-D.wadkins-agentproto-action-determinability] Wadkins, D., "Independent Determinability of Agent Actions", Work in Progress, Internet-Draft, draft-wadkins- agentproto-action-determinability-00, 10 September 2026, . Work in progress. Revision, date, title, and author verified active at the datatracker on 2026-09-16. [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . Newton Expires 6 April 2027 [Page 37] Internet-Draft Agreement Evidence October 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026, . Informational. Title, author list, and June 2026 publication date verified at the RFC Editor and the datatracker on 2026-09-16. Appendix A. 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. Newton Expires 6 April 2027 [Page 38] Internet-Draft Agreement Evidence October 2026 +==========================+=======================+ | Document subject | Concordia Protocol | | | Specification section | +==========================+=======================+ | Scope and non-goals | Sections 1.4 and 2 | +--------------------------+-----------------------+ | Terms and agreement | Sections 3 and 4 | | surfaces | | +--------------------------+-----------------------+ | Lifecycle and offer | Sections 5 and 6 | | grammar | | +--------------------------+-----------------------+ | JCS, signatures, and | Sections 9.2, 9.3, | | transcript digest fields | and 9.6.2 | +--------------------------+-----------------------+ | Attestation schema and | Sections 9.6.2 and | | fields | 9.6.3 | +--------------------------+-----------------------+ | Approval, fulfillment, | Sections 9.6.4a | | revocation | 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 | Section 9.8 | | organization | | +--------------------------+-----------------------+ | Typed references | Section 11.5 | +--------------------------+-----------------------+ Table 7: Crosswalk to the Source Specification Appendix B. Implementation Status This appendix is informative and is provided in the form described by [RFC7942]. The RFC Editor is requested to remove this appendix before publication, along with the reference to [RFC7942]. 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 Newton Expires 6 April 2027 [Page 39] Internet-Draft Agreement Evidence October 2026 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: Section 11 and Section 12 carry requirement keywords that this table does not enumerate, among them the resource limits of Section 11.7 that steps 1 and 2 of Section 10 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. +========================================+=========+================+ | Requirement | Section | Status | +========================================+=========+================+ | A relying party MAY calculate its | 4.3 | implemented at | | own score from the behavioral | | 847729cd [E1] | | signals or ignore them | | | +----------------------------------------+---------+----------------+ | The four unused bits of the final | 4.4 | scheduled for | Newton Expires 6 April 2027 [Page 40] Internet-Draft Agreement Evidence October 2026 | encoded signature group MUST be | | 0.6.0 | | zero | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a | 4.4 | scheduled for | | signature value of the wrong | | 0.6.0 | | length, with absent or misplaced | | | | padding, with a character outside | | | | the alphabet, with whitespace, or | | | | with non-zero unused bits | | | +----------------------------------------+---------+----------------+ | A recipient MUST compare decoded | 4.4 | scheduled for | | signature octets rather than | | 0.6.0 | | encoded characters | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a | 4.4 | scheduled for | | timestamp whose offset is not the | | 0.6.0 | | single character Z | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a | 4.4 | scheduled for | | fractional second of more than | | 0.6.0 | | three digits | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a string | 4.4 | scheduled for | | member that is not in | | 0.6.0 | | Normalization Form C | | | +----------------------------------------+---------+----------------+ | A recipient MUST compare | 4.4 | scheduled for | | identifier strings only after | | 0.6.0 | | normalization | | | +----------------------------------------+---------+----------------+ | A member declared free of | 4.4 | scheduled for | | whitespace MUST NOT carry a | | 0.6.0 | | White_Space character | | | +----------------------------------------+---------+----------------+ | Such a member MUST NOT carry a | 4.4 | scheduled for | | character in the listed control | | 0.6.0 | | and format ranges | | | +----------------------------------------+---------+----------------+ | A recipient MUST preserve an | 4.4 | implemented at | | unrecognized reference type or | | 847729cd [E2] | | relationship as an opaque string | | | +----------------------------------------+---------+----------------+ | A verifier MUST NOT treat a | 4.4 | scheduled for | | parties element signature as | | 0.6.0 | | evidence that an outcome is | | | | outcome-bound | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a | 4.4 | implemented at | Newton Expires 6 April 2027 [Page 41] Internet-Draft Agreement Evidence October 2026 | value_range outside the | | 847729cd [E3] | | enumerated bucket vocabulary | | | +----------------------------------------+---------+----------------+ | A signer and a verifier MUST | 5.1 | implemented at | | canonicalize the same logical | | 847729cd [E4] | | object to identical UTF-8 bytes | | | +----------------------------------------+---------+----------------+ | Implementations MUST reject | 5.1 | scheduled for | | values that cannot be represented | | 0.6.0 | | under Section 4.4 and the | | | | canonicalization rules | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject a numeric | 5.1 | scheduled for | | value outside its stated range | | 0.6.0 | +----------------------------------------+---------+----------------+ | A recipient MUST reject an object | 5.1 | scheduled for | | carrying a repeated member name, | | 0.6.0 | | detected at parse time | | | +----------------------------------------+---------+----------------+ | A recipient MUST reject input | 5.1 | scheduled for | | that is not well-formed UTF-8 or | | 0.6.0 | | that carries an unpaired | | | | surrogate | | | +----------------------------------------+---------+----------------+ | Implementations MUST verify | 5.2 | scheduled for | | Ed25519 signatures with the | | 0.6.0 | | cofactorless equation of RFC 8032 | | | +----------------------------------------+---------+----------------+ | Implementations MUST reject a | 5.2 | scheduled for | | non-canonical R or S, an | | 0.6.0 | | unreduced S, or a public key not | | | | of order L | | | +----------------------------------------+---------+----------------+ | An implementation MUST derive the | 6.1 | implemented at | | countersignature payload by the | | 847729cd [E5] | | four steps of this section | | | +----------------------------------------+---------+----------------+ | A verifier MUST NOT credit an | 6.2 | scheduled for | | outcome as outcome-bound unless | | 0.6.0 | | all seven listed conditions hold | | | +----------------------------------------+---------+----------------+ | A well-formed artifact below | 6.2 | implemented at | | 0.5.0 MAY be retained as a record | | 847729cd [E6] | | of its own contents | | | +----------------------------------------+---------+----------------+ | Its outcome MUST NOT be credited | 6.2 | scheduled for | | as outcome-bound | | 0.6.0 | +----------------------------------------+---------+----------------+ Newton Expires 6 April 2027 [Page 42] Internet-Draft Agreement Evidence October 2026 | It MUST NOT be reported as | 6.2 | scheduled for | | current | | 0.6.0 | +----------------------------------------+---------+----------------+ | An assembling implementation MUST | 7 | specified | | NOT populate any member with an | | here, no | | exact negotiated term value | | implementation | +----------------------------------------+---------+----------------+ | It MUST NOT include an item or | 7 | specified | | service description beyond | | here, no | | category and value_range | | implementation | +----------------------------------------+---------+----------------+ | It MUST NOT include free-text | 7 | specified | | reasoning copied from negotiation | | here, no | | messages | | implementation | +----------------------------------------+---------+----------------+ | It MUST NOT include the identity | 7 | specified | | of a represented human or | | here, no | | organization | | implementation | +----------------------------------------+---------+----------------+ | It MUST draw value_range from the | 7 | implemented at | | fixed bucket vocabulary | | 847729cd [E3] | +----------------------------------------+---------+----------------+ | It MUST reject every other | 7 | implemented at | | value_range value rather than | | 847729cd [E3] | | coerce it | | | +----------------------------------------+---------+----------------+ | It MUST encode category to the | 7 | implemented at | | dotted lowercase taxonomy grammar | | 847729cd [E3] | +----------------------------------------+---------+----------------+ | It MUST reject every other | 7 | implemented at | | category value rather than | | 847729cd [E3] | | coercing it | | | +----------------------------------------+---------+----------------+ | It MAY omit category for | 7 | implemented at | | additional privacy | | 847729cd [E7] | +----------------------------------------+---------+----------------+ | It MUST reject a reference | 7 | implemented at | | identifier longer than 256 octets | | 847729cd [E3] | | or carrying whitespace | | | +----------------------------------------+---------+----------------+ | It MUST reject an attestation | 7 | implemented at | | carrying more than 32 references | | 847729cd [E3] | +----------------------------------------+---------+----------------+ | It MUST keep summary within 1024 | 7 | scheduled for | | Unicode scalar values | | 0.6.0 | +----------------------------------------+---------+----------------+ | It MUST NOT copy a negotiated | 7 | specified | | term value or free-text reasoning | | here, no | Newton Expires 6 April 2027 [Page 43] Internet-Draft Agreement Evidence October 2026 | into summary | | implementation | +----------------------------------------+---------+----------------+ | A relying party MUST configure a | 8.1 | scheduled for | | maximum evidence age, a maximum | | 0.6.0 | | validity lifetime, and a skew | | | | allowance within the stated | | | | ceilings | | | +----------------------------------------+---------+----------------+ | A relying party MUST reject | 8.1 | scheduled for | | evidence exceeding any of those | | 0.6.0 | | three | | | +----------------------------------------+---------+----------------+ | A relying party MAY configure | 8.1 | scheduled for | | tighter values | | 0.6.0 | +----------------------------------------+---------+----------------+ | A relying party MUST enforce its | 8.1 | scheduled for | | own evidence age independently of | | 0.6.0 | | the signed window | | | +----------------------------------------+---------+----------------+ | A relying party MUST reject a | 8.1 | scheduled for | | timestamp or interval start | | 0.6.0 | | future-dated beyond the skew | | | | allowance | | | +----------------------------------------+---------+----------------+ | A verifier MUST enforce the | 8.1 | scheduled for | | finite skew bound and fail closed | | 0.6.0 | | outside it | | | +----------------------------------------+---------+----------------+ | A relying party MUST reject an | 8.1 | implemented at | | attestation whose validity | | 847729cd [E6] | | interval has ended | | | +----------------------------------------+---------+----------------+ | A relying party MAY apply a | 8.1 | scheduled for | | tighter freshness bound than the | | 0.6.0 | | signer asserted | | | +----------------------------------------+---------+----------------+ | A party MUST NOT countersign a | 8.2 | implemented at | | validity lifetime exceeding 90 | | 847729cd [E6] | | days | | | +----------------------------------------+---------+----------------+ | A party MAY apply a shorter | 8.2 | implemented at | | maximum lifetime | | 847729cd [E6] | +----------------------------------------+---------+----------------+ | validity_temporal is REQUIRED on | 8.3 | implemented at | | every attestation at 0.5.0 and | | 847729cd [E8] | | later | | | +----------------------------------------+---------+----------------+ | A verifier MUST reject a | 8.3 | scheduled for | Newton Expires 6 April 2027 [Page 44] Internet-Draft Agreement Evidence October 2026 | validity_temporal object that is | | 0.6.0 | | malformed, carries an extra | | | | member, or expresses an empty or | | | | reversed interval | | | +----------------------------------------+---------+----------------+ | A relying party SHOULD keep a | 8.4 | scheduled for | | consumption record for an | | 0.6.0 | | attestation it acts on, keyed by | | | | attestation_id | | | +----------------------------------------+---------+----------------+ | A relying party MUST perform the | 10 | scheduled for | | nine verification steps in fail- | | 0.6.0 | | closed order | | | +----------------------------------------+---------+----------------+ | An artifact below 0.5.0 | 10 | scheduled for | | terminates at step 2 with the | | 0.6.0 | | terminal state legacy, and the | | | | verifier MUST NOT apply any later | | | | step to it | | | +----------------------------------------+---------+----------------+ | The verifier MUST treat | 10 | scheduled for | | revocation status as undetermined | | 0.6.0 | | in each of the three named cases | | | +----------------------------------------+---------+----------------+ | In each of those cases the | 10 | scheduled for | | verifier MUST NOT report the | | 0.6.0 | | artifact as current | | | +----------------------------------------+---------+----------------+ | In each of those cases the | 10 | scheduled for | | verifier MUST carry the artifact | | 0.6.0 | | to step 9 as bound-only | | | +----------------------------------------+---------+----------------+ | An implementation MAY expose | 10 | scheduled for | | diagnostic detail alongside the | | 0.6.0 | | terminal state it reports | | | +----------------------------------------+---------+----------------+ | An implementation MUST NOT report | 10 | scheduled for | | any state name other than the | | 0.6.0 | | four terminal states | | | +----------------------------------------+---------+----------------+ | An implementation MUST NOT | 10 | scheduled for | | silently replace one terminal | | 0.6.0 | | state with another | | | +----------------------------------------+---------+----------------+ | An implementation MUST NOT report | 10 | scheduled for | | a legacy or bound-only artifact | | 0.6.0 | | as current | | | +----------------------------------------+---------+----------------+ Newton Expires 6 April 2027 [Page 45] Internet-Draft Agreement Evidence October 2026 | A typed failure reason MUST | 10 | scheduled for | | distinguish a result the checks | | 0.6.0 | | cannot produce from one this | | | | verifier could not reach | | | +----------------------------------------+---------+----------------+ | A typed failure reason MUST NOT | 10 | scheduled for | | report the second of those as the | | 0.6.0 | | first | | | +----------------------------------------+---------+----------------+ Table 8: Per-Requirement Implementation Status 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 Newton Expires 6 April 2027 [Page 46] Internet-Draft Agreement Evidence October 2026 define those artifacts. An artifact at version 0.5.0 or later carrying a removed member is rejected at step 2 of Section 10, 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. Appendix C. EP-AEC Compatibility This appendix is informative and creates no normative dependency. [I-D.schrock-ep-authorization-evidence-chain], 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 Section 10 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 (Section 6.2), and it determines revocation status only when the deployment supplies a revocation source (Section 10). 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 (Section 4 and Section 10) is complete and independently useful without it. Author's Address Erik Newton Email: eriknewton@gmail.com Newton Expires 6 April 2027 [Page 47]