SCITT S. Mih Internet-Draft Action State Group, Inc. Intended status: Standards Track Y. Zhang Expires: 22 April 2027 Independent 19 October 2026 AAC Evidence Bundle draft-mih-zhang-agent-disclosure-bundle-01 Abstract This document defines the AAC Evidence Bundle, a portable presentation and verification container for an Agent Action Capsule and the records that make its evidentiary claim intelligible. A permalink carries a bundle in its URL fragment, an offline HTML report carries a bundle in its shell, and a hosted report serves a bundle at its URL. The bundle does not alter any enclosed Capsule. It declares its citation closure and any missing cited records, carries verified disclosure preimages as a bundle-level overlay, separates three different completeness claims, and permits independently specified extension blocks and countersignatures: signatures by a party other than the producer over the bundle digest, each accompanied by a statement of which claims that party recomputed and with what result. 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/. 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 22 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Mih & Zhang Expires 22 April 2027 [Page 1] Internet-Draft AAC Evidence Bundle October 2026 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Evidence Bundle Object . . . . . . . . . . . . . . . . . . . 4 4. Citation Closure . . . . . . . . . . . . . . . . . . . . . . 5 5. Bundle-Level Disclosures . . . . . . . . . . . . . . . . . . 6 6. Completeness Claims and Log Membership . . . . . . . . . . . 7 7. Typed Extensions . . . . . . . . . . . . . . . . . . . . . . 8 7.1. The producer-key/v1 Extension . . . . . . . . . . . . . . 8 7.2. The composed/v1 Extension . . . . . . . . . . . . . . . . 9 7.2.1. Block . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2.2. Members and Outcomes . . . . . . . . . . . . . . . . 12 7.2.3. Composition Closure . . . . . . . . . . . . . . . . . 13 7.2.4. Joins . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2.5. Observers and Redundancy . . . . . . . . . . . . . . 15 7.2.6. Composed Digest . . . . . . . . . . . . . . . . . . . 16 7.2.7. Verifying composed/v1 . . . . . . . . . . . . . . . . 17 7.3. Provisional Extension Kinds . . . . . . . . . . . . . . . 18 8. Bundle Digest and Countersignatures . . . . . . . . . . . . . 18 8.1. The countersign/v1 Entry . . . . . . . . . . . . . . . . 18 8.2. Verifying a countersign/v1 Entry . . . . . . . . . . . . 20 8.3. Self-Countersignature . . . . . . . . . . . . . . . . . . 21 9. Fragment Codec . . . . . . . . . . . . . . . . . . . . . . . 21 10. Verification . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11.1. composed/v1 . . . . . . . . . . . . . . . . . . . . . . 23 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 26 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Mih & Zhang Expires 22 April 2027 [Page 2] Internet-Draft AAC Evidence Bundle October 2026 1. Introduction A Capsule proves the identity and claimed content of one action. An audit report normally needs more: the report Capsule, its chain of judgments or adjudications, the turns cited by those records, selected disclosed preimages, and the log evidence that supports a claim about coverage. Passing these items as unrelated files produces a presentation that a verifier cannot describe precisely. The AAC Evidence Bundle is that unit of evidence. It is deliberately a presentation-layer object: the Capsules in records retain their original bytes, identities, signatures, and registrations. The same bundle can be encoded in a URL fragment, embedded in an offline HTML shell, or obtained from a hosted report URL. These are transports for one object, not distinct evidence formats. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bundle: An AAC Evidence Bundle as defined in Section 3. Root Capsule: The Capsule identified by the Bundle's root member. The Bundle's evidence claim is made from this Capsule outward through its declared closure. JSON-DIGEST: The lowercase-hex SHA-256 digest of UTF8(JCS(value)), using [RFC8785] over the whole recursively canonicalized JSON value with no member filtering, as defined by [I-D.mih-scitt-agent-action-capsule]. Countersignature: A countersignature is a signature by a party other than the producer over a bundle digest, accompanied by a statement of which claims that party recomputed and with what result. A report is a bundle. Countersigner: The party that makes a countersignature. A Mih & Zhang Expires 22 April 2027 [Page 3] Internet-Draft AAC Evidence Bundle October 2026 countersigner works in the manner of an Auditor [RFC9943]: it independently recomputes checks over a Bundle it was given and signs a statement of the results -- a list of what it recomputed, never an opinion. A countersigner MAY register that statement as a Signed Statement with a Transparency Service, in which case the entry carries the Receipt; the Receipt proves that the statement is in that log and says nothing about the Bundle. Which producers a countersigner accepts Bundles from is its own admission rule, outside this document. Self-countersignature: An entry in countersignatures whose signer key is the producer's key (Section 8.3). It is well-formed and is rendered as not independent. countersignatures is a member name. An entry is a statement by a party other than the producer that it recomputed named checks over the bundle digest, in the manner of an Auditor [RFC9943]. It is not a COSE countersignature [RFC9338], not a Receipt [RFC9942], and not a Transparency Service function. WITHHELD: The disclosure state of an eligible member absent from the Bundle-level disclosure overlay. It is neither an empty value nor a verification failure. The terms "Capsule", "capsule_id", chain.parent_capsule_id, references, seq, leaf_index, and log_coordinates are as defined in [I-D.mih-scitt-agent-action-capsule]. 3. Evidence Bundle Object A Bundle is a JSON [RFC8259] object with this shape. Ellipses denote values defined by this document or a registered extension; they do not authorize untyped replacement formats. Mih & Zhang Expires 22 April 2027 [Page 4] Internet-Draft AAC Evidence Bundle October 2026 { "bundle_version": "2", "bundle_kind": "evidence-bundle/v2", "root": "", "records": [ ... ], "completeness": { "closure_depth": 2, "records_mode": "complete|declared_incomplete", "payloads_mode": "all|selected", "suppressed_fields": [ ... ], "missing": [ "", ... ] }, "disclosures": { "": { "": "" } }, "disclosure_record": "", "completeness_certificate": { ... }, "checkpoint": { ... }, "verification": { ... }, "extensions": { "": { ... } }, "countersignatures": [ ... ] } bundle_version and bundle_kind are REQUIRED and MUST be respectively "2" and "evidence-bundle/v2". root, records, and completeness are REQUIRED. root is the lowercase-hex capsule_id of one record in records. Every records element MUST be an unmodified Capsule object conforming to [I-D.mih-scitt-agent-action-capsule]; duplicate capsule_id values are not permitted. All other members shown are OPTIONAL unless a claim in this document requires them. A receiver MUST reject an object with an unknown bundle_version or bundle_kind as an AAC Evidence Bundle, rather than silently applying version-2 verification rules. payloads_mode states whether the producer included all payload material it chose to carry (all) or only a selected subset (selected). suppressed_fields names fields intentionally not carried by the Bundle; it does not turn an absent disclosure into an empty value or a failure. 4. Citation Closure Citation closure is declared, not assumed. Starting at root, a producer MUST traverse chain.parent_capsule_id and every references[].digest transitively through completeness.closure_depth edges. The default depth is 2 when the member is absent: report to judgments or adjudications, then to turns. A producer using a different depth MUST state that non-negative JSON integer explicitly. Mih & Zhang Expires 22 April 2027 [Page 5] Internet-Draft AAC Evidence Bundle October 2026 For each target reached within that depth, the Bundle MUST either supply the cited Capsule in records with a matching identity or list its digest once in completeness.missing. A target MUST NOT be silently dropped. records_mode MUST be complete exactly when missing is absent or empty, and MUST be declared_incomplete exactly when it is non-empty. A verifier MUST report the latter as declared incomplete, not as complete and not as an unexplained failure. A supplied record whose computed capsule_id does not match the chain target or reference digest is not supplied evidence for that target. The closure declaration says nothing about records beyond its stated depth. A verifier MUST report the depth it applied and MUST NOT infer unbounded ancestry or citation completeness from the presence of a short chain. 5. Bundle-Level Disclosures disclosures is a Bundle-level overlay keyed first by the enclosed Capsule's capsule_id, then by the disclosure member name: "disclosures": { "": { "agent_input": { ... }, "agent_output": { ... } } } It has the same eligibility and DE-3 digest rule as the per-Capsule Disclosure Envelope in [I-D.mih-agent-disclosure-envelope]. The member name selects that draft's registered committed-digest path in the specified Capsule. For every disclosed member, a verifier MUST compute JSON-DIGEST(revealed preimage) and compare it to the committed digest at that registered path in that records element. A match is REVEALED; a mismatch is a failed verification of that disclosed content. A member absent from this overlay is WITHHELD, never blank and never failed. The overlay is carried once per Bundle rather than by wrapping each Capsule in {capsule, disclosures}. It MUST NOT alter an enclosed Capsule or its capsule_id. An overlay key not naming a supplied record, or a member not eligible under the Disclosure Envelope registry, is a disclosure finding and MUST NOT be treated as a successful revelation. disclosure_record, when present, identifies the Capsule that records the act of sealing or issuing these disclosures; it is evidence about that act and does not replace the DE-3 check. Mih & Zhang Expires 22 April 2027 [Page 6] Internet-Draft AAC Evidence Bundle October 2026 6. Completeness Claims and Log Membership completeness_certificate and checkpoint, when supplied, support three separate claims. A verifier MUST report each claim independently. The composed/v1 extension adds a fourth claim, composition closure (Section 7.2.3), which is reported separately from these three. 1. *Graph closure*: every citation reached under Section 4 is supplied with matching identity or explicitly listed in completeness.missing. 2. *Interval coverage*: the claimed sequence interval is bound to a checkpointed range root. Without a verified Receipt [RFC9942] over the checkpoint from a Transparency Service, or a verified checkpoint signature, this is only relative to a producer- asserted checkpoint. 3. *Per-record membership*: every supplied record is bound to its claimed log position under that range root. The certificate MUST state its log_id, range root, first and last seq, and the proof material that binds that range root to checkpoint. A signed range proof that binds only the first and last record proves endpoint inclusion only: an interior record can be deleted or replaced while such a proof still passes. A verifier MUST NOT report whole-range completeness from endpoint inclusion alone. A verifier MUST verify an included Receipt [RFC9942] over the checkpoint, or the checkpoint signature, before reporting interval coverage or per- record membership as independently verified. Otherwise it MUST explicitly label those claims checkpoint_unverified and describe them as relative to a producer-asserted checkpoint. The portable checkpoint signature member is checkpoint.cose, an unpadded base64url CLL COSE checkpoint. A verifier that implements this member MUST verify it and require its log identifier, MMR size, and root to equal the certificate and checkpoint values before removing the qualifier. Mih & Zhang Expires 22 April 2027 [Page 7] Internet-Draft AAC Evidence Bundle October 2026 For the third claim, every supplied record MUST either carry a membership entry within the declared interval or be explicitly listed in completeness.missing. A membership entry or record whose seq is outside the interval MUST be rejected. Each membership entry MUST carry log_coordinates stating its claimed position and an inclusion proof to the certificate's range root. The base profile's terms apply exactly: seq is the 1-based log position and leaf_index = seq - 1 is the zero-based MMR index. log_coordinates states which index is used. The verifier MUST verify every inclusion proof at its stated leaf_index, require the proof's leaf_index to equal that coordinate and its size to equal checkpoint.mmr_size, and bind the record to the range root; it MUST NOT substitute an endpoint proof for a missing per-record proof. A record without a valid proof may remain usable for graph closure but does not satisfy per-record membership. 7. Typed Extensions extensions, when present, is an object keyed by a registered Evidence Bundle extension kind. The member name declares the kind and its value is that kind's block. The extension kind registry is Specification Required. A registered specification defines its block shape and any semantic checks. For example, a company-side row model such as report/v1 is permitted only as such an extension; this neutral core does not define, parse, or own its rows. Extensions are included in the bundle digest (Section 8). A verifier that does not implement a registered extension kind MUST preserve its integrity status as digest-covered, report the block as uninterpreted, and MUST NOT apply that block's semantics. An unknown kind MUST NOT alter the core Capsule, closure, disclosure, or membership checks. 7.1. The producer-key/v1 Extension The producer-key/v1 extension kind declares the key of the producer that assembled the Bundle: "extensions": { "producer-key/v1": { "public_key": "<64 lowercase hex>" } } public_key is the producer's 32-byte Ed25519 [RFC8032] public key as 64 lowercase hexadecimal characters. The block carries one key. A producer MUST NOT add other members to the block, and a verifier MUST ignore any it finds. Like every extension, the block is covered by the bundle digest, so a countersignature's over binds the declaration, and adding, removing, or changing the declaration afterwards makes that entry invalid. Mih & Zhang Expires 22 April 2027 [Page 8] Internet-Draft AAC Evidence Bundle October 2026 A verifier that implements this kind uses public_key for one purpose only: it adds the key to the producer's keys when determining independence (Section 8.3), so that a countersign/v1 entry whose signer.key_id equals it is reported as not independent. The declaration can only cause an entry to be reported as not independent. It MUST NOT cause any entry to be reported as independent, resolved, or valid, and it MUST NOT change any other result. It is not a claim of identity or of authority, and a verifier MUST NOT present it as one. The absence of this extension says nothing about whether any entry is independent. The block is malformed when it is not an object, or when public_key is absent, is not a string, or is not exactly 64 lowercase hexadecimal characters. A verifier MUST ignore a malformed block when determining independence, MUST NOT fail the Bundle or any claim because of it, and still treats the block as digest-covered. 7.2. The composed/v1 Extension The composed/v1 extension kind carries an evidence set built from the answers of several responders as one portable object. Each responder answered one Evidence Request ([I-D.mih-agent-evidence-request]) with exactly one of three outcomes: * an artifact, here an Evidence Bundle; * a signed refusal; * a recorded absence. Each answer is a _member_ of the composition. The block declares: * each member's digest and outcome; * the observer that produced each member; * the joins between members; * a _composed digest_ that a judgment or other record can cite as the exact evidence set it was made from. The containing Bundle is an ordinary evidence-bundle/v2. Its root is the composing party's own record, and its core checks apply unchanged. The extension adds a set of member bundles alongside that record; it does not change what records, root or completeness mean. Mih & Zhang Expires 22 April 2027 [Page 9] Internet-Draft AAC Evidence Bundle October 2026 "extensions": { "composed/v1": { "members": [ { "id": "", "observer": "", "request_digest": "<64 hex>", "outcome": "artifact", "digest": "<64 hex>", "bundle": { ... } }, { "id": "", "observer": "", "request_digest": "<64 hex>", "outcome": "refusal", "digest": "<64 hex>", "refusal": { ... } } ], "observers": [ { "id": "", "role": "", "custody_domain": "