AAC Evidence Bundle

3.1. Empty-History Bundles

An empty-history Bundle shows that a log stream has no history to disclose. A stream that was never started and a history that was cleared read the same. Clearing a history starts a new stream, with a new log_id, under the same key. It never rewrites or truncates the old stream's log, and a checkpoint that does so is inconsistent with that log's earlier checkpoints.¶

An empty-history Bundle has an empty records array and no root member. root MUST be absent exactly when records is empty. In an empty-history Bundle:¶

• completeness.records_mode MUST be complete, completeness.missing MUST be absent or empty, and completeness.payloads_mode MUST be none;¶

• completeness_certificate, disclosures and disclosure_record MUST be absent;¶

• checkpoint, with checkpoint.cose, SHOULD be present when the stream has a checkpoint: its first checkpoint, or its latest one while it still holds no record. A stream that was never started has none.¶

A Bundle with no root that is not a well-formed empty-history Bundle is malformed.¶

A verifier reports a well-formed empty-history Bundle as no history. It is well formed: a verifier MUST NOT report it as failed, and MUST NOT report it as an absence (Section 8.2.2). Of its claims (Section 6), graph closure passes, since there is nothing to close, and interval coverage and per-record membership are not established, with the finding no_records. When checkpoint.cose verifies, the verifier reports the checkpoint's signed timestamp with the result, as no history since that time. Otherwise it reports no history without a date.¶

6.1. Certificate Modes

completeness.selection names the mode in which completeness_certificate is read:¶

• Absent (the Bundle has no selection member): a range certificate, as described above. Its interval ends at the checkpoint's last leaf.¶

• producer-selected: a producer-selected certificate (Section 6.2).¶

This document defines no other value. A verifier that meets a selection value it does not implement, including a value that is not a string (null among them), MUST report interval coverage and per-record membership as not established (finding certificate_mode_unsupported). It MUST NOT report either claim as failed because of the mode, MUST NOT read the certificate under another mode, and MUST NOT report the Bundle as invalid on that ground. Graph closure, disclosures, extensions and countersignatures are unaffected.¶

The same rule applies to a verifier that predates a mode: a verifier that does not implement producer-selected certificates reports such a Bundle's interval coverage and per-record membership as not established, never as failed. A Bundle in a mode the verifier lacks is unverified in that respect; it is not evidence of tampering, and reporting it as invalid would make an honest Bundle indistinguishable from an altered one. The selection member is the producer's to write, and so is any edit to a Bundle after it is made: setting an unknown mode can turn a failing claim into one that is not established, but never into one that is established (Section 12).¶

6.2. Producer-Selected Certificates

A producer-selected Bundle carries records that its producer chose from a log, each proven on its own, and makes no claim about the records between them. Its completeness.selection is producer-selected. Its certificate carries log_id, range_root and memberships. It carries no range: first_seq, last_seq, body_digests and range_proof are not part of it, and a verifier does not read them. It MUST NOT carry non_record_leaves (Section 6.3).¶

"completeness": {
  "closure_depth": 0,
  "records_mode": "complete",
  "payloads_mode": "none",
  "suppressed_fields": [],
  "missing": [],
  "selection": "producer-selected"
},
"completeness_certificate": {
  "log_id": "<log identifier>",
  "range_root": "<checkpoint root>",
  "memberships": { "<capsule_id>": { "log_coordinates": { ... },
                                      "inclusion_proof": { ... } } }
}

A verifier that implements this mode:¶

• reports interval coverage as not established (finding selection_not_checkable): there is no interval;¶

• verifies per-record membership record by record. range_root MUST equal the checkpoint's root, and the certificate's log_id the checkpoint's log_id. Each record's membership entry MUST carry log_coordinates naming the checkpoint's log_id, a seq of at least 1 that no other entry claims, and leaf_index = seq - 1, and an inclusion proof at that index whose size equals checkpoint.mmr_size and that binds the record's capsule_id to the root. A membership entry for a record the Bundle does not carry is a failure. Otherwise the rules of Section 6 apply, including the checkpoint_unverified label;¶

• reports a certificate that carries non_record_leaves as invalid.¶

When checkpoint.cose does not verify, or a stated value (including the certificate's log_id) contradicts it, the checkpoint anchors no record: the verifier reports per-record membership as not established, labelled checkpoint_unverified, except that a certificate that carries non_record_leaves still fails it.¶

A producer-selected Bundle is therefore never complete as to its log: a verifier MUST NOT report it as such, and its best result is that every carried record is a member of the checkpointed log. A changed record or proof fails per-record membership exactly as in a range Bundle. Graph closure, which is about citations, not log positions, is unaffected by the mode.¶

6.3. Non-Record Leaves

A log can hold leaves that are not records. The Evidence Layer [I-D.mih-agent-evidence-layer] reserves the record_type value padding for records a store appends so that a checkpoint's size falls on a bucket boundary (its Section 12.1). A store that pads before every checkpoint usually has a padding leaf at the checkpoint's last leaf, so a range ending there always covers one. A range certificate covers such leaves in its member non_record_leaves, which carries each one in full:¶

"non_record_leaves": [
  { "seq": 6,
    "content": { "capsule_id": "<64 hex>", "record_type": "padding",
                 "epistemic_type": "producer_claim",
                 "store_nonce": "<64 hex>" } }
]

non_record_leaves is an array. Each element is an object with seq, the leaf's 1-based log position within [first_seq, last_seq], and content, the leaf's content. A digest alone is not accepted in place of content: a bare leaf value could be the identifier of a Capsule that the Bundle thereby hides. Members of an element other than seq and content are ignored.¶

The padding leaf. This document defines one non-record leaf type, padding. The members of a padding record are those of [I-D.mih-agent-evidence-layer] Section 12.1: record_type padding, epistemic_type producer_claim, and store_nonce, 32 bytes as 64 lowercase hexadecimal characters. That document fixes the members but not their serialization or the record's identifier, so this document states both for a padding leaf in a Bundle. Its content is a JSON object with exactly four members: those three and capsule_id. capsule_id is 64 lowercase hexadecimal characters, and is the JSON-DIGEST (Section 2) of the object formed by the other three members. The leaf value is capsule_id. A store's local-only producer envelope (signature, key_id) is not part of content. (Moving this rule into the Evidence Layer awaits a later revision of that document.)¶

Checking an element. A verifier reads the elements in order. For each one:¶

1. An element that is not an object is malformed (finding non_record_leaf_element_invalid).¶

2. A seq that is not an integer within [first_seq, last_seq], that any membership entry states in its log_coordinates (whether or not that entry is otherwise valid), or that is the seq of an earlier element, is invalid (finding non_record_leaf_seq_invalid); the element accounts for no position.¶

3. Otherwise the element accounts for its seq. Then:¶

   • when content is not an object, or its record_type is not a string, the element is malformed (finding non_record_leaf_malformed);¶

   • when record_type is not padding, the leaf is of a type this document does not define (finding non_record_leaf_type_unsupported), and the verifier checks nothing further about it;¶

   • when the padding content does not have exactly the four members above, each in the form above, with epistemic_type equal to producer_claim, it is malformed (finding non_record_leaf_malformed);¶

   • the verifier recomputes the leaf value from the other three members and requires it to equal both content.capsule_id and body_digests[seq - first_seq]; otherwise the leaf does not match (finding non_record_leaf_mismatch).¶

A non_record_leaves value that is not an array is malformed (finding non_record_leaves_malformed) and accounts for no position.¶

Per-position accounting. For per-record membership over a range, every seq in [first_seq, last_seq] MUST be accounted for by exactly one of a record's membership entry and a non_record_leaves element. Each position is then:¶

• verified: a record's verified membership, or a padding leaf that recomputes to its body digest;¶

• unsupported: a leaf of a type the verifier does not implement; or¶

• unaccounted: neither, or an element that failed a check above (finding membership_record_missing for a position with neither).¶

Any failure fails per-record membership, whatever else is unsupported. When nothing fails and some position is unsupported, per-record membership is not established: the verifier MUST NOT report it as established, and MUST NOT report it as failed. Otherwise the rules of Section 6 apply. A verifier that implements this member therefore no longer rejects a range because it contains padding records, as [I-D.mih-agent-evidence-layer] Section 12.1 requires. A verifier that does not implement the member ignores it, as it ignores any member it does not know, and then reports every padding position as missing, which fails per-record membership. A producer therefore SHOULD NOT emit non_record_leaves to readers that do not implement this revision; until it can, a producer-selected certificate states what it can prove without it.¶

A non-record leaf is not a record. It never appears in records, never counts as a record for graph closure, disclosures or any count a verifier reports, and is never the target of a citation. Leaves other than padding, such as a store's checkpoint stamps, are not covered by this document. A range over a log that contains one is reported, at best, as not established through non_record_leaf_type_unsupported; a producer that needs a Bundle over such a log without that result uses a producer-selected certificate.¶

7.1. Statuses

Each category has exactly one status, written in upper case:¶

AVAILABLE, PARTIAL, WITHHELD and DELETED are retention states of the Evidence Layer [I-D.mih-agent-evidence-layer], with the same meanings, applied to a category rather than to one record's payload. This document defines UNDISCLOSED and ABSENT. ABSENT is the producer's asserted absence in the Evidence Layer's sense ("Three Kinds of No"): its own unproven claim about its own store, never a non-membership proof and never the requester's recorded absence of [I-D.mih-agent-evidence-request]. The retention state LEGAL_HOLD is not a status: it changes what may happen to evidence, not what is offered.¶

UNDISCLOSED MUST carry policy_uri, an absolute URI ([RFC3986], Section 4.3) naming the policy under which the status is not disclosed; policy_uri MAY accompany any other status. WITHHELD and UNDISCLOSED are different statements and MUST NOT be conflated: WITHHELD says evidence may exist and is not released; UNDISCLOSED says nothing about whether any exists.¶

7.2. Signature

signer.key_id is a 32-byte Ed25519 [RFC8032] public key as 64 lowercase hexadecimal characters. signature is the Ed25519 signature, as 128 lowercase hexadecimal characters, under that key over the signing input¶

UTF8(JCS({"category_coverage": <the member without signature>,
          "root": <the Bundle's root>}))

Including root binds the declaration to the root record of the Bundle it was made for: a signed declaration copied into a Bundle with another root does not verify. It does not bind the rest of the Bundle; a Bundle with the same root and other records carries it unchanged, and only the bundle digest (Section 9) tells the two Bundles apart. The signature attributes the declaration to the holder of the key. It does not establish who that holder is; a verifier MAY compare signer.key_id with the producer's keys (Section 9.3) and report the result.¶

7.3. Verifier Properties

A verifier that implements this member reports the following properties, each as exactly one of PASS, FAIL, NOT_PRESENT, NOT_CHECKED and INCONCLUSIVE, as the definition of each property below assigns them. A Bundle without the member has no category properties.¶

category_coverage_form:

PASS when the member is as described above, including a policy_uri for every UNDISCLOSED status; otherwise FAIL. When it is FAIL, every other property is NOT_CHECKED.¶

category_coverage_signature:

NOT_PRESENT when the member carries no signature; PASS when the signature verifies; FAIL otherwise, including when the signing input has no JCS serialization (for example, a number JCS cannot represent).¶

category_coverage_set_registered:

NOT_PRESENT for a private (x-) set; INCONCLUSIVE when the verifier does not know the set; FAIL when it knows the set and a declared category is not one of its names; PASS otherwise.¶

category_coverage_request:

NOT_CHECKED when the verifier does not have the Evidence Request; otherwise FAIL when request_digest is present and is not that request's digest, computed over its octets before they are parsed; otherwise NOT_CHECKED when the request cannot be read, or its categories field is malformed ([I-D.mih-agent-evidence-request]); NOT_PRESENT when the request has no categories field; FAIL when the request names another set, or a requested category has no entry; PASS otherwise.¶

category_coverage_consistency:

NOT_CHECKED when the verifier cannot assign every record the Bundle carries to a category, or to none (the set's definition says how): a record it cannot assign could be in any category; FAIL when a record the Bundle carries belongs to a category declared ABSENT or WITHHELD; PASS otherwise. A record in a DELETED or UNDISCLOSED category is not a contradiction, and an AVAILABLE category with no record in the Bundle is not one either: the Bundle may cover less than the producer offers.¶

Each property stands alone. A verifier MUST report them separately and MUST NOT combine them, or the statuses, into a count, a percentage, a score or a claim of completeness. It MUST NOT report a PASS of every property as proof that the producer offered everything it holds. A FAIL of category_coverage_form, category_coverage_signature or category_coverage_consistency is a failed check of the Bundle; the other properties are reported and change no other result. Category coverage is reported apart from the completeness claims of Section 6 and changes none of them.¶

A verifier that does not implement this member follows the rule for any member it does not know: it reports nothing about it, and the member stays covered by the bundle digest.¶

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

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

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

"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" /
             "controller_binding"
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}"

controller-binding = {
  binding_version: "controller-binding/0",
  claim: binding-claim,
  method: tstr,                  ; a verification method token
  keys: [key-id, key-id],        ; two distinct keys, ascending
  issued_at: binding-time,       ; the ceremony, as stated
  not_before: binding-time,      ; not later than issued_at
  not_after: binding-time,       ; later than issued_at
  revocation: "revocation_statement/0",
  nonce: tstr,                   ; non-empty, chosen per ceremony
  sigs: [* binding-sig],
  ? key_types: [tstr, tstr],     ; one per entry of keys, in order
  ? delegator: key-id,           ; delegated_by only: one of keys
  ? credential: binding-credential,
                                 ; same_organization_credentialed
}

binding-claim = "same_controller_asserted" / "delegated_by" /
                "same_organization_credentialed"
binding-sig = { key_id: key-id, sig: any }   ; sig-hex for ed25519
binding-credential = {
  issuer: key-id,
  method: tstr,
  digest: digest-hex,
}

binding-revocation = {
  revocation_version: "controller-binding-revocation/0",
  binding: digest-hex,           ; the binding digest
  key_id: key-id,                ; one of the binding's keys
  revoked_at: binding-time,
  sig: sig-hex,
}

key-id       = text .regexp "[0-9a-f]{64}"
sig-hex      = text .regexp "[0-9a-f]{128}"
binding-time = text .regexp
  "[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z"

8.3. Provisional Extension Kinds

The interim registry (Section 14) also records two extension kinds held for ratification and not registered: sd-jwt-issuers/v1, the issuer keys under which SD-JWT presentations [RFC9901] in a revealed agent_input are verified offline, and disclosure-policy-decisions/v1, the per-Capsule disclosure-policy decision that a constraint record binds by digest. This document does not define them. A verifier that does not implement them treats them as it treats any extension kind it does not implement (Section 8): digest-covered and uninterpreted.¶

9.1. The countersign/v1 Entry

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

type, signer, over, statement, and signature are REQUIRED; receipt is OPTIONAL.¶

signer.id identifies the countersigner, for example a did:web identifier. signer.key_id is the countersigner's 32-byte Ed25519 [RFC8032] public key as 64 lowercase hexadecimal characters: the key itself, not a digest of it, so that a verifier holding only the entry can check the signature offline.¶

over is the bundle digest (Section 9) of the Bundle the countersigner recomputed.¶

statement says what the countersigner recomputed and with what result.¶

• checks is a non-empty array. Each element names one check in name, a short phrase for what was recomputed, and gives its result, which is exactly one of the five values below. A check name is unique within a statement.¶

• recomputed_at is the [RFC3339] UTC time, with a "Z" suffix, at which the countersigner finished recomputing.¶

• scope.ledger_id identifies the ledger whose records the Bundle carries, as the issuer identified it to the countersigner. scope.closure_depth is the closure depth the countersigner applied (Section 4). scope.period, when present, is the {from, to} interval of [RFC3339] timestamps the checks covered; it is absent when the Bundle declares no such interval.¶

Each result stands alone. A statement MUST NOT carry an aggregate result, a score, a rating, or a claim of compliance, and a verifier MUST NOT derive one from the checks. Capture coverage, meaning whether every action that occurred was recorded, cannot be recomputed from the records a Bundle carries; a statement MUST NOT report it as a check result. Profile identifiers naming a recomputation policy, when a later revision adds them, use the countersign. prefix; this document defines none.¶

signature is the Ed25519 signature, as 128 lowercase hexadecimal characters, over the signing input UTF8(JCS({"over": over, "signer": signer, "statement": statement, "type": type})). The signature binds the Bundle, the signer's identity and what the countersigner says about it; signer is the entry's signer object exactly as it appears on the wire.¶

receipt, when present, is a Receipt [RFC9942] showing the statement was registered with a Transparency Service, in that service's receipt encoding. A verifier that cannot verify it MUST report it as unverified; its absence does not invalidate the entry.¶

A verifier MUST ignore entry members not defined here, and they MUST NOT change any result it reports.¶

9.2. Verifying a countersign/v1 Entry

A verifier MUST, for each countersign/v1 entry:¶

1. recompute the bundle digest and compare it to over. An entry whose over differs is not a countersignature of this Bundle and MUST be reported as invalid;¶

2. verify signature over the signing input under signer.key_id. An entry whose signature fails is invalid, and its checks MUST NOT be displayed as results;¶

3. determine independence as in Section 9.3.¶

A verifier MAY resolve signer.key_id against a directory of countersigners that it or the relying party chooses, to put a name to the key. No directory is privileged, and this document defines none. A verifier reports each countersign/v1 entry as exactly one of invalid, not independent, unresolved signer (independent, and the key is in no directory consulted), or resolved (independent, and the key is found). It MUST attribute each check and result to the signer, as the signer's statement, and MUST NOT present them as its own findings.¶

9.3. Self-Countersignature

A countersignature is a self-countersignature when signer.key_id equals the producer's key: the kid of a Producer Envelope over any record in records ([I-D.mih-scitt-agent-action-capsule]), the public_key of a well-formed producer-key/v1 extension (Section 8.1), or any other key the verifier holds for that producer. A self-countersignature is a well-formed entry that does not meet the definition of a countersignature, because its signer is the producer. A verifier MUST NOT reject it for being one, and MUST render it as not independent, never as a countersignature by a party other than the producer. The verifier computes independence itself for each entry; no entry member and no directory entry can change that result, and a producer key declaration can only change it to not independent.¶

12.1. composed/v1

• Omitted participants. The composing party chooses whom to list. Composition closure proves that every declared member is present or declared missing. It cannot reveal a participant that the composing party never listed. not_requested makes a known omission explicit. Completeness against the real set of participants needs an independent statement of that set, such as a coordinator's sealed topology. A verifier MUST NOT describe composition closure as completeness of participation.¶

• Declarations versus derivations. Declared join states are re-derived; a mismatch fails. Declared custody can only downgrade (Section 8.2.6). Nothing a producer declares can make two observers independent.¶

• Controller bindings. A binding can only make an agreement redundant (Section 8.2.6); no binding, revocation or failed signature can make two members corroborating. Two keys bound by their holders can sign agreeing records, and without the redundancy rule they would read as two issuers. A verifier knows only the revocation statements it received: the party presenting a composition can leave out a revocation, and a controller_binding agreement is then reported redundant all the same, never more. A revocation the producer did not account for derives unjoined and fails a declared agree (join_state_mismatch).¶

• No history. An empty-history Bundle (Section 3.1) is its producer's statement that its stream holds no record. Its signed checkpoint shows that the stream exists, under which key, and the size of its log at that time. It carries no certificate, so nothing shows that no leaf of that log is a record. A verifier MUST NOT present no history as evidence that no action took place. Because it is an artifact, never an absence, a cleared or unstarted history cannot be read as a responder that did not answer.¶

• Outcomes. Keeping refusal and absence distinct is evidentiary: synthesizing either one from the other forges the stronger record from the weaker.¶

12.2. Category Coverage

A category declaration is the producer's statement about itself (Section 7). A producer that chooses its own categories can declare whatever is favorable to it; this is why a private set is never reported as registered, and why a verifier reports properties rather than a verdict of completeness. A signed ABSENT is attributable and can be contradicted by records a counterparty holds, but it is not evidence that nothing exists. Including the Bundle's root in the signing input stops a declaration made for one root record from being presented with another; a countersignature over the bundle digest is what binds it to the whole Bundle.¶

15.1. Normative References

[I-D.mih-agent-disclosure-envelope]

Mih, S., "Disclosure Envelope Profile for Agent Action Capsules", Work in Progress, Internet-Draft, draft-mih-agent-disclosure-envelope-00, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-agent-disclosure-envelope-00>.

[I-D.mih-agent-evidence-request]

Mih, S., "An Interaction Model for Requesting Verifiable Evidence", Work in Progress, Internet-Draft, draft-mih-agent-evidence-request-01, 29 October 2026, <https://datatracker.ietf.org/doc/html/draft-mih-agent-evidence-request-01>.

[I-D.mih-scitt-agent-action-capsule]

Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action-capsule-05, n.d., <https://datatracker.ietf.org/doc/html/draft-mih-scitt-agent-action-capsule-05>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC6901]

Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/rfc/rfc6901>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9942]

Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, <https://www.rfc-editor.org/rfc/rfc9942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

15.2. Informative References

[I-D.mih-agent-evidence-layer]

Mih, S., "Evidence Layer", Work in Progress, Internet-Draft, draft-mih-agent-evidence-layer-00, 3 October 2026, <https://datatracker.ietf.org/doc/html/draft-mih-agent-evidence-layer-00>.

[I-D.mih-sokolov-scitt-payload-binding]

Mih, S. and A. Sokolov, "Canonicalization Declaration for SCITT Signed Statements", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding-06, 26 October 2026, <https://datatracker.ietf.org/doc/html/draft-mih-sokolov-scitt-payload-binding-06>.

[RFC9338]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Countersignatures", STD 96, RFC 9338, DOI 10.17487/RFC9338, December 2022, <https://www.rfc-editor.org/rfc/rfc9338>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.