AAC Evidence Bundle

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

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

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

{
  "bundle_version": "2",
  "bundle_kind": "evidence-bundle/v2",
  "root": "<capsule_id>",
  "records": [ ... ],
  "completeness": {
    "closure_depth": 2,
    "records_mode": "complete|declared_incomplete",
    "payloads_mode": "all|selected",
    "suppressed_fields": [ ... ],
    "missing": [ "<cited capsule digest>", ... ]
  },
  "disclosures": {
    "<capsule_id>": { "<member>": "<revealed preimage>" }
  },
  "disclosure_record": "<capsule_id>",
  "completeness_certificate": { ... },
  "checkpoint": { ... },
  "verification": { ... },
  "extensions": { "<registered kind>": { ... } },
  "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.¶

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": {
  "<capsule_id>": {
    "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.¶

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

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

"extensions": {
  "producer-key/v1": { "public_key": "<64 lowercase hex>" }
}

"extensions": {
  "composed/v1": {
    "members": [
      { "id": "<member id>", "observer": "<observer id>",
        "request_digest": "<64 hex>", "outcome": "artifact",
        "digest": "<64 hex>", "bundle": { ... } },
      { "id": "<member id>", "observer": "<observer id>",
        "request_digest": "<64 hex>", "outcome": "refusal",
        "digest": "<64 hex>", "refusal": { ... } }
    ],
    "observers": [
      { "id": "<observer id>", "role": "<role>",
        "custody_domain": "<label>" }
    ],
    "joins": [
      { "members": ["<member id>", "<member id>"],
        "basis": "pre_agreed_identifier",
        "pointer": "<JSON Pointer>",
        "identifier_digest": "<64 hex>",
        "compare": ["<JSON Pointer>"],
        "state": "agree" }
    ],
    "not_requested": [ "<participant id>" ],
    "missing": [ "<member id>" ],
    "composed_digest": "<64 hex>"
  }
}

composed-v1 = {
  members: [+ composed-member],
  observers: [+ composed-observer],
  ? joins: [* composed-join],
  ? not_requested: [* label-id],
  ? missing: [* label-id],
  composed_digest: digest-hex,
}

composed-member = artifact-member / refusal-member / absence-member

member-common = (
  id: label-id,
  observer: label-id,             ; an observers[].id
  request_digest: digest-hex,     ; the Evidence Request this answers
  digest: digest-hex,             ; see "Members and Outcomes"
)

artifact-member = { member-common, outcome: "artifact",
                    ? bundle: { * tstr => any },   ; a Bundle
                    ? response: artifact-response }
refusal-member  = { member-common, outcome: "refusal",
                    ? refusal: signed-refusal }
absence-member  = { member-common, outcome: "absence",
                    ? absence: recorded-absence }

signed-refusal = {                ; as received, unmodified
  request_digest: digest-hex,
  reason: tstr,                   ; Evidence Request refusal reason
  issued_at: tstr,                ; RFC 3339
  * tstr => any,                  ; deployment signature members
}

artifact-response = {             ; as received, minus artifact bytes
  request_digest: digest-hex,
  artifact_digest: digest-hex,
  * tstr => any,                  ; deployment members and signature
}

recorded-absence = {              ; the requester's own record
  request_digest: digest-hex,
  window: { from: tstr, to: tstr },   ; RFC 3339
  ? route: tstr,
  ? commitment: digest-hex,       ; a retention commitment it held
}

composed-observer = {
  id: label-id,
  role: tstr,                     ; see "Observers and Redundancy"
  custody_domain: tstr,           ; opaque, compared octet-for-octet
}

composed-join = {
  members: [label-id, label-id],  ; two distinct ids, ascending
  basis: join-basis,
  ? pointer: tstr,                ; RFC 6901 JSON Pointer
  ? identifier_digest: digest-hex,
  ? compare: [+ tstr],            ; RFC 6901 JSON Pointers
  state: join-state,
}

join-basis = "pre_agreed_identifier" / "shared_artifact_digest" /
             "issued_receipt" / "same_interval"
join-state = "agree" / "mismatch" / "unjoined" / "one_sided"

label-id   = text .regexp "[A-Za-z0-9._:-]{1,128}"
digest-hex = text .regexp "[0-9a-f]{64}"

8. Bundle Digest and Countersignatures

The bundle digest is SHA-256(UTF8(JCS(canonical bundle form))), rendered as 64 lowercase hexadecimal characters. The canonical bundle form is the Bundle with countersignatures omitted. countersignatures is excluded so that independent parties can add signatures without changing the digest they sign; every other present Bundle member, including extensions, participates.¶

countersignatures, when present, is an array of objects. Each object MUST carry type and the type's signature encoding, and signs the bundle digest. An object whose signer is a party other than the producer is a countersignature (Section 2). This document does not define who populates the slot or whether a relying party should rely on a given signer.¶

The registered types are cose-sign1 and countersign/v1. A cose-sign1 object is {type: "cose-sign1", signature: "<base64url tagged COSE_Sign1>"}. It is a reserved neutral slot whose population and verification are future scope; a current verifier MUST surface each such entry as unverified and MUST NOT present pass-through data as a verified countersignature. The countersign/v1 object is defined in Section 8.1. A verifier MUST report an entry of a type it does not implement as unverified and MUST NOT let it change any other result. An entry with no type member is the legacy form of countersign/v1. A verifier MUST process it as countersign/v1, and its signing input then uses the value countersign/v1 for type. A producer MUST NOT emit the legacy form.¶

{
  "type": "countersign/v1",
  "signer": { "id": "<signer identifier>", "key_id": "<64 hex>" },
  "over": "<bundle digest>",
  "statement": {
    "checks": [ {"name": "<check>", "result": "<result>"}, ... ],
    "recomputed_at": "<RFC 3339 UTC timestamp>",
    "scope": {
      "ledger_id": "<ledger identifier>",
      "period": { "from": "<RFC 3339>", "to": "<RFC 3339>" },
      "closure_depth": 2
    }
  },
  "signature": "<128 hex>",
  "receipt": { ... }
}

9. Fragment Codec

The common permalink codec is exact. To encode a Bundle in a URL fragment, a producer MUST serialize the whole Bundle with JCS, including recursive sort_keys object-member ordering, UTF-8 encode the resulting JSON text, and encode those bytes with RFC 4648 base64url [RFC4648] Section 5 without padding. The resulting unescaped ASCII string is the fragment value after #. A decoder MUST base64url-decode the unpadded fragment, UTF-8 decode it, parse it as JSON, and then apply the Bundle checks in this document.¶

The /v/<id> route carries a Bundle of one using this same codec; /bundle uses no different decoder. The path is a locator only. URL fragments are not sent in HTTP requests, so a hosted service receives a Bundle only when it is otherwise uploaded or embedded in the returned report.¶

10. Verification

verification, when present, is producer self-report. It MAY record tool versions, performed checks, or findings, but it is not proof and MUST NOT replace independent verification of Capsules, disclosures, closure, certificates, checkpoints, or countersignatures. A verifier MUST label it as producer self-report.¶

A conforming verifier MUST at minimum compute the Bundle digest, verify each enclosed Capsule under the base profile, apply Section 4 and Section 5, and report graph closure, interval coverage, and per-record membership as separate results. It MUST distinguish WITHHELD, REVEALED-match, REVEALED-mismatch, declared incomplete, and absent or invalid membership proofs.¶

11. Security Considerations

The Bundle does not make omitted evidence disappear. Its explicit missing declaration is necessary to prevent a short report from being represented as a complete closure. Range endpoints are not a substitute for per-record membership: endpoint-only proofs leave interior substitution and deletion undetected. Disclosures are not signatures and are untrusted until their DE-3 digest comparison succeeds. Fragments can be copied or changed by a party hosting a link, so every received Bundle requires independent verification. Unknown extension kinds are integrity-covered but semantically untrusted.¶

A countersignature's statement and signer are what a relying party reads, so both are inside the signing input (Section 8.1); a signature over the bundle digest alone would let anyone holding the Bundle rewrite a failed result as established, or attribute the entry to a different signer identifier, without detection. A verified signature establishes who made the statement, not that the relying party should rely on that party: signer trust, and the choice of any directory used to put a name to a key, are outside this document. A self-countersignature is not a second party's check, and rendering it as one would present the producer's own claim as independent corroboration; Section 8.3 forbids that. A producer-key/v1 declaration can only cause an entry to be reported as not independent: a producer that declares a key it does not hold weakens only its own Bundle's countersignatures, and a producer that countersigns with a key it does not declare is still reported at most as an unresolved signer unless a directory the verifier chose lists that key. Results are listed per check and never combined, because an aggregate would hide a failed or not checked result behind a total.¶

12. Privacy Considerations

A Bundle reveals a preimage only through its disclosure overlay (Section 5); a member absent from the overlay stays WITHHELD. For the composed/v1 extension (Section 7.2):¶

• Join identifiers enter only as digests (identifier_digest).¶

• custody_domain is an opaque label and SHOULD NOT be a network address, an account identifier or a personal name.¶

• Withholding a member's body (missing) keeps the composed digest stable. A judgment can therefore be checked against a composition presented to an audience that may not see every member.¶

13. IANA Considerations

IANA is requested to create the "AAC Evidence Bundle Parameters" registry group with these Specification Required registries, using [RFC8174] and [RFC2119] terminology and the designated-expert criteria of [RFC8126]:¶

1. "Evidence Bundle kind", initial value evidence-bundle/v2.¶

2. "Evidence Bundle extension kind", initial values producer-key/v1 (Section 7.1) and composed/v1 (Section 7.2). A registered specification defines each block; private x- prefixed kinds are not registered. The kinds sd-jwt-issuers/v1 and disclosure-policy-decisions/v1 (Section 7.3) are not initial values.¶

3. "Evidence Bundle countersignature type", initial values cose-sign1 (Section 8) and countersign/v1 (Section 8.1).¶

Until IANA registry creation, the interim registry of record is REGISTRY.md in the source repository of [I-D.mih-scitt-agent-action-capsule]. It records the same values and policy.¶

14. References

Change Log

Since -00:¶

• Countersignatures: defined the countersign/v1 countersignature entry, its statement, and its five check results; defined countersignature, countersigner, and self-countersignature, and required a self-countersignature to be rendered as not independent; registered countersign/v1 as a second countersignature type; an entry with no type is processed as countersign/v1 (the legacy form).¶

• Defined and registered the producer-key/v1 extension kind, which declares the producer's key and can only cause a countersignature to be reported as not independent.¶

• Defined and registered the composed/v1 extension kind: one member per responder carrying its Evidence Request outcome (artifact, refusal or absence); observers with a role and a custody domain; joins whose declared state (agree, mismatch, unjoined or one_sided) a verifier re-derives; a fourth completeness claim, composition closure; same-custody agreement reported as redundant, not corroborating; and a composed digest (JCS, SHA-256) over the member, observer, join and not_requested declarations. Added Privacy Considerations.¶

• Noted two provisional extension kinds, sd-jwt-issuers/v1 and disclosure-policy-decisions/v1, held for ratification in the interim registry and not defined by this document.¶

Acknowledgments

The authors thank the SCITT working group and the Action State Group architecture review for the evidence-bundle starting shape.¶

Authors' Addresses