open-standards/wai/extensions/bearer-receipts.md

# WAI Extension: Bearer Receipts

> Status: Draft. Registers the record `wai.bearer.receipts`: one receipt on every bearer. A
> publisher's group and object receipts ([jwp-receipts](jwp-receipts.md) §2.4.1, §2.4.2) are
> the same bytes whether a group travels over a two-way relay chain, IP multicast or a
> broadcast bearer with no return path. What a bearer changes is what can honestly be said
> about delivery, and this extension says it beside the receipt, in two claim classes of
> jwp-receipts: a publisher's **transmission** claim (§4, jwp-receipts §2.4.14), which declares
> the bearer a group was sent over and attests transmission, never delivery; and a sink's
> **reconciliation** claim (§5, jwp-receipts §2.4.15), signed later and out of band, which
> attests the objects the sink received by a Merkle root under the group's own tree. A
> verifier derives from them what a relying party may state about a group (§6), an upper
> bound on each receiver's share of a shared transmission's energy (§7), and confirms keys
> on a bearer with no return path under anchors provisioned in advance (§8). §9 maps the
> carriage onto the bearers. WAI defines no transport, here as elsewhere
> ([moq-streaming-format](moq-streaming-format.md)). The reference implementation is the `bearer_receipts` module of `wai-rs` (feature
> `bearer_receipts`), with the two classes' bodies in `claim_receipt::bearer`; the corpus is
> [`live-conformance/bearers/`](../live-conformance/bearers/), and its second implementation
> is `live-conformance/bearer_verify.py`.
> §13 writes a reconciliation and a holdings record compactly for return paths whose messages
> hold few bytes; its reference is the `compact_return` module (features `bearer_receipts` and
> `holdings`), its corpus [`live-conformance/compact-return/`](../live-conformance/compact-return/)
> and its second implementation `live-conformance/compact_return_verify.py`.
> Keywords **MUST**, **MUST NOT**, **SHOULD**, **MAY** are RFC 2119/8174.
>
> Texts read for this revision, each at the edition named: ETSI TS 103 769 V1.2.1 (2024-11);
> ETSI TS 103 770 V1.2.1 (2024-09); ATSC A/331:2026-04, A/333:2026-04 and A/360:2026-08; 3GPP
> TS 26.346 V19.3.0, TS 26.517 V19.3.0 and TS 26.502 V19.6.0; RFC 6726;
> `draft-ramadan-moq-multicast-02` (§1 to §6; the latest revision in the IETF archive on 10
> November 2026, with -00 and -01 beside it) and `draft-ietf-moq-transport-22`, Internet-Drafts;
> ETSI TS 102 796 V1.8.1 (2026-09) and ETSI TS 102 809 V1.3.1. A clause number of one of
> them in this text is that edition's.

## 1. Scope

In scope: the bearer classes (§2); why the bearer is declared beside the receipt and not in
it (§3); the transmission claim (§4) and the reconciliation claim (§5), their bodies, rules
and context checks; the verdict a verifier derives for one group from its receipts and those
claims (§6); the upper bound on a receiver's share of a shared transmission's energy (§7);
verification with no return path (§8); the mappings onto bearers (§9); and a compact form of
reconciliations and holdings records for return paths whose messages hold few bytes, carried in
fragments (§13).

When each object passes on a bearer with no return path, and with which forward error
correction, is [carousel](carousel.md)'s: a publisher's `schedule` claim beside the transmission
claim here, from which a verifier derives when a receiver within a loss bound holds each object.

A node that sends again, over a bearer instance of its own, objects it holds of a group another key
signed, declares that instance in a `cache-transmission` claim, and reconciliations over it are
counted beside the publisher's instances: [cache-authority](cache-authority.md) §5, §7.

Out of scope: a transport or a bearer; a reception-reporting protocol — a reconciliation
travels on whatever path a sink later has, as a receipt file (http-delivery §8.1) or inside a
bearer's own reporting (§9); a pre-emption authority ([unidirectional-delivery](unidirectional-delivery.md)
§3 registers none, and nor does this extension); and any statement of rendering. No receipt
over a bearer with no return path can prove rendering, and nothing here attempts it.

Relationship to the core spec: `wai.bearer.receipts` is a **record** ([SPEC](../SPEC.md)
§5): the transmission and reconciliation claims are signed records a WAI tool emits and
verifies. It names no payload format and is not dispatchable.

## 2. Terms

- **Bearer**: what carries a group's objects from a publisher to sinks. Its **class** is one of:
  - `bidirectional`: each sink is reached over a path that can carry its statements back,
    such as a relay chain or unicast HTTP;
  - `multicast`: one transmission reaches every sink that joined it, with no per-sink path on
    the bearer itself; a sink may have another path;
  - `unidirectional`: one transmission, and no path back from any sink.
- **Bearer instance**: one transmission a publisher made, or a node that sends again what it holds
  ([cache-authority](cache-authority.md) §5), named by an absolute URI, its
  `bearer_id`: a multicast session, a broadcast service, a relay chain's origin. WAI reads
  nothing from it and compares it byte for byte.
- **Transmission**: putting a group's objects and their receipts onto a bearer instance.
  **Delivery**: a sink receiving them. A transmission is not a delivery, on any bearer.
- **Sink**: a receiver that verifies what it received under [jwp-receipts](jwp-receipts.md)
  §3. **Relying party**: anyone else who reads a group's receipts and claims.
- **Group**, **link hash**, **leaf**, **root**: as jwp-receipts §2.2, §2.4.1 and §3 step 3.
  `delivered-verified` and `inclusion-verified`: as jwp-receipts §3.

## 3. One receipt on every bearer

The group receipt signs its objects' root, its coordinates, its times and its publisher
(jwp-receipts §2.3). It names no bearer, and this extension adds no member to it. The bearer
is declared beside the receipt, in a transmission claim signed by the group's own key and
naming the group by its link hash (§4). Three facts fix that form:

- **A group is not tied to one bearer.** A group may be sent over a relay chain and a
  broadcast at once, and carried again later by another. A bearer inside the signed payload
  would make one group per bearer, each with its own link hash, and the chain of a track
  (jwp-receipts §3 step 3) could link through only one of them.
- **The bearer is a fact about a transmission, not about the bytes.** The receipt attests the
  bytes; a declaration attests what the publisher did with them, and is a statement of its own
  with its own signature.
- **Every receipt already issued keeps verifying.** A group carried before this extension, or
  carried by a party that does not use it, verifies exactly as before; what is missing is a
  declaration, which is reported as missing (§6.5), never inferred.

So the "MUST declare the bearer" of [unidirectional-delivery](unidirectional-delivery.md) §4
is met by a signed declaration that changes no byte of the receipt it declares. A sink that
holds a group's objects and receipts verifies them under jwp-receipts §3 the same way on
every bearer and reaches the same verdicts (`delivered-verified` for each object whose bytes
it holds): the corpus carries one group, byte for byte, on all three classes (§11). What
differs between bearers is what anyone other than that sink may state about delivery (§6),
and how a receiver's share of the transmission's energy is bounded (§7).

## 4. The transmission claim (`class: "transmission"`)

A publisher that sends a group over a bearer **MAY** declare the transmission in a
`transmission` claim, one per bearer instance, and **MUST** where
[unidirectional-delivery](unidirectional-delivery.md) §4 requires it. Its `subject_type` is
`receipt` and its `subject` the group receipt's link hash (jwp-receipts §3 step 3). It is
signed by the key that signed the group. It attests that the publisher transmitted the group
over the bearer instance it names, and nothing about what any sink received.

### 4.1 Body

| member | type | meaning |
|---|---|---|
| `bearer` | string | The bearer's class: `bidirectional`, `multicast` or `unidirectional` (§2). |
| `bearer_id` | absolute URI | The bearer instance (§2). |
| `energy` | object or `null` | The energy the bearer spent transmitting the group on this instance, every repetition included, written as jwp-receipts §2.4.12 writes a session's `energy`: `{ "joules_micro", "energy_provenance", "energy_uncertainty", "energy_counter_filtering", "energy_calibration_ref" }`. `null` when the transmission was not metered, never a figure of 0 ([energy-measurement](energy-measurement.md) §2). It is not the group's `joules_total`, which is the energy of producing the objects. |
| `attests` | string | **MUST** be `"transmitted"`. Any string passes step 2; another value is refused at step 4. |

`bearer` is read at jwp-receipts §3.1 step 2 against its enumeration (`field_type`), and
`bearer_id` as an absolute URI.

### 4.2 Rules

Checked at jwp-receipts §3.1 step 4, in this order:

1. `attests` **MUST** be `"transmitted"` (`transmission_not_transmitted`): a declaration that
   says it attests anything more is refused, never read as a weaker one.
2. Where `energy` is not `null`, its `joules_micro` **MUST NOT** be 0
   (`energy_zero_figure`), and its class is admitted as jwp-receipts §2.4.5 rule 2 admits one
   (`energy_unknown_acquisition`, `energy_legacy_acquisition`,
   `energy_acquisition_evidence`).

### 4.3 Against the group

Checked at jwp-receipts §3.1 step 6 against the group receipt the verifier holds, which has
passed jwp-receipts §3 steps 1 and 2 (`context_invalid` otherwise; another receipt is
`context_mismatch`). In order:

1. the group's link hash is the claim's `subject` (`transmission_subject_mismatch`): a
   declaration over another group declares nothing about this one;
2. the claim's `signer_pubkey` is the group's (`transmission_signer_mismatch`): only the
   publisher declares its own transmission.

A transmission claim checked without the group stops at step 5 and is not counted by §6.

### 4.4 Authority

Confirmed under jwp-receipts §7, a transmission claim needs the authority `transmission`,
which is not pinned-only and is not `delivery`. Its energy figure, where `energy` is not
`null`, is a second item, as a session's is (jwp-receipts §7.5): it needs `transmission` and
the energy authority of its class, so a hardware-class figure is confirmed only under a pinned
anchor, and a verifier reports the declaration's confirmation and its figure's side by side.

## 5. The reconciliation claim (`class: "reconciliation"`)

A sink that received objects of a group **MAY** later sign which ones, in a `reconciliation`
claim. Its `subject_type` is `receipt` and its `subject` the group receipt's link hash. It is
signed by the sink, never by the publisher. It is not a hop: it is never a group's parent,
never in the publisher's chain, and nothing in the publisher's chain changes when it arrives.

### 5.1 Body

| member | type | meaning |
|---|---|---|
| `bearer` | string | The class of the bearer the sink received over (§2). |
| `bearer_id` | absolute URI | The bearer instance it received over: the `bearer_id` of the publisher's transmission claim, or of a node's cache-transmission claim, for that instance. |
| `leaf_count` | integer | The group's `leaf_count`. |
| `received` | hex | A bitmap of ⌈`leaf_count` / 8⌉ bytes. Object *i* is bit `0x80 >> (i mod 8)` of byte ⌊*i* / 8⌋, so the hexadecimal reads left to right in object order; the bit is set exactly when the sink accepted object *i* under jwp-receipts §3 steps 1–6 over its bytes. |
| `received_root` | 32 B hex | The root jwp-receipts §2.2 computes over the leaves of the received objects, in increasing `leaf_index`, each leaf in the form its object receipt takes (legacy or labelled). With every bit set it is the group's `root_hash`. |
| `attests` | string | **MUST** be `"received"`. Any string passes step 2; another value is refused at step 4. |

The root is a commitment under the group's own tree, so it is checked against the
publisher's root without the objects' bytes (§5.3).

### 5.2 Rules

Checked at jwp-receipts §3.1 step 4, in this order:

1. `attests` **MUST** be `"received"` (`reconciliation_not_received`).
2. `leaf_count` is at least 1, `received` holds exactly ⌈`leaf_count` / 8⌉ bytes, no bit at
   or past `leaf_count` is set, and at least one bit is set (`reconciliation_bitmap_malformed`).
   A sink that received nothing has nothing to reconcile.

### 5.3 Against the group and its objects

Checked at jwp-receipts §3.1 step 6 against the group receipt the verifier holds, which has
passed jwp-receipts §3 steps 1 and 2 (`context_invalid`, `context_mismatch` as §4.3), and the
object receipts it holds under that group, each of which has passed jwp-receipts §3 step 5 —
verified by inclusion at least. In order:

1. the group's link hash is the claim's `subject` (`reconciliation_subject_mismatch`);
2. the claim's `signer_pubkey` is not the group's (`reconciliation_by_publisher`): a
   publisher's statement that it received its own objects is not a reconciliation;
3. `leaf_count` is the group's (`reconciliation_leaf_count_mismatch`);
4. with every bit set, `received_root` is the group's `root_hash`; otherwise the verifier
   holds an object receipt at every set bit (`reconciliation_objects_not_held`, recoverable
   by obtaining them, never accepted silently) and `received_root` is the root over their
   leaves (`reconciliation_root_mismatch`). A root over a leaf that is not the group's at its
   position — a hash not in the group — is refused here.

A reconciliation checked without the group stops at step 5 and is not counted by §6.

### 5.4 What it attests

An accepted reconciliation establishes that its signer says it received the objects its
bitmap names, with the bytes their receipts commit to. It does not establish that the signer
held those bytes: content hashes travel with the receipts, so a party that saw only the
receipts can sign one. It never attests presentation, rendering or timeliness. Like a
`binding-recovery` record (jwp-receipts §2.6.3), it attests less than a hop would, and says so
in-band (`attests`).

### 5.5 Authority

Confirmed under jwp-receipts §7, a reconciliation needs the authority `reconciliation`, which
is not pinned-only and is not `delivery`. A sink signs under an origin's key where its origin
speaks for it, and under a `did:key` otherwise, which is unconfirmed (jwp-receipts §7.4
step 1), as a sink's `reconstruct-session` claim is.

## 6. The bearer verdict

What a verifier may state about one group, from its receipts and the claims about it.

### 6.1 Inputs

The group receipt; the object receipts the verifier holds under it, each with the object's
envelope bytes where it holds them; the transmission and reconciliation claims it holds about
the group, each signer's in the order of its chain; optionally, for a verifier that is itself
a sink, the bearer class and instance it received the group over (§6.5); optionally, a
statement offered about the group (§6.4); and optionally, for a relying party that counts
receivers only by keys it has confirmed, the set of those keys (§7).

### 6.2 Steps

1. **The group.** jwp-receipts §3 steps 1 and 2. A group that fails is refused with that
   step's reason, and nothing below is derived from it. (Its chain is jwp-receipts §3 step
   3's, and unchanged.)
2. **The objects.** Each object receipt is checked against the group: with the envelope, by
   jwp-receipts §3 steps 4–6 (`delivered-verified`); without it, by step 5
   (`inclusion-verified`); or refused with its step's reason. These verdicts do not depend on
   the bearer, the declarations or the reconciliations.
3. **The claims.** Each claim, in order, under jwp-receipts §3.1 steps 1–5, each signer's
   previous claim being the last of its claims held before it here; then step 6, a
   transmission claim by §4.3 and a reconciliation by §5.3 against the object receipts that
   passed step 2. A claim of another class is `context_mismatch` at step 6. A claim refused at
   any step takes no further part.
4. **The declarations.** The accepted transmission claims, by `bearer_id`. Two with one
   `bearer_id` and different bodies set aside every declaration of that instance
   (`bearer_contradicted`): a publisher that contradicts itself about one transmission has
   declared neither. Two with the same body are one declaration.
5. **The reconciliations**, each accepted one in order. It is set aside, and counted nowhere,
   at the first of these that holds: step 4 set aside the declarations of its `bearer_id`
   (`bearer_contradicted`); no declaration has its `bearer_id` (`bearer_not_declared`); the
   declaration names another `bearer` (`bearer_contradicted`); the verifier counts only
   confirmed keys and its key is not among them (`sink_not_confirmed`). Otherwise it is
   **counted** for its bearer instance. A second counted reconciliation of one key for one
   instance adds no sink (`reconciliation_duplicate_sink`): its bits are joined to the first's.
6. **The counts.** `sinks`: the distinct keys with a counted reconciliation; `whole`: those
   whose joined bits, over every instance, cover every object of the group; for each object,
   the number of distinct keys whose joined bits hold it; and for each declaration, the
   distinct keys counted for its instance.

### 6.3 Status

- **`published`**: no declaration stands. The group verifies; nothing is stated about where
  it went.
- **`transmitted`**: at least one declaration stands, and no reconciliation is counted. The
  publisher sent it over the bearers declared; nothing is stated about any sink.
- **`reconciled`**: at least one reconciliation is counted. `sinks` keys say they received
  objects of the group, out of band and on their own authority, and `whole` of them say they
  received every object.

A verifier **MUST NOT** report a group, or anything read from it, as delivered to anyone but
itself on the strength of the publisher's receipts and declarations: the receipts attest
publication, the declarations transmission. `delivered-verified` stays the verdict of a sink
over bytes it holds (jwp-receipts §3).

### 6.4 Statements offered about a group

A verifier **MAY** be asked to check a statement made about the group:

- **transmitted over a bearer class**: holds when a declaration of that class stands, and is
  otherwise refused (`bearer_not_declared`);
- **delivered to *k* sinks** (*k* at least 1): holds when `whole` is at least *k*. With `whole`
  0 it is refused (`delivery_not_reconciled`), whatever was declared: a transmitted-only group
  presented as delivered is refused here. With `whole` from 1 to *k* − 1 it is refused
  (`delivery_exceeds_reconciled`).

### 6.5 A sink's own bearer

A sink knows the bearer instance it received over. Beside its object verdicts, and never
changing them, it reports the group's declaration for that instance: `declared` when one
stands with the sink's class; `bearer_contradicted` when one stands with another class, or
step 4 set the instance's declarations aside; and `bearer_not_declared` when none names the
instance. A group received over a unidirectional bearer with no declaration is
[unidirectional-delivery](unidirectional-delivery.md) §4's missing declaration.

## 7. Energy per receiver on a shared transmission

A transmission's energy is spent once, whoever receives it. On a multicast or broadcast
bearer the number of receivers is not known, and **unknown is not zero**: no figure divided by
an assumed audience is a measurement of anyone's share. What a verifier states instead is an
upper bound, for each declaration of §6.2 step 4 whose `energy` is not `null`:

```
per_receiver_upper_bound = ⌈ joules_micro / max(1, n) ⌉
```

where `n` is the number of distinct keys counted for that instance (§6.2 step 6).

- **It bounds an allocation, not a reading.** Dividing one transmission's figure among its
  receivers is an allocation of that figure (as energy-steering §3.3 says of a hop shared by
  pathways); no receiver's own energy was read. A verifier **MUST** report it as a bound, named
  so, and **MUST NOT** report it as any receiver's measured energy.
- **Why it is an upper bound.** Every receiver of the transmission shares the one figure. If
  the counted keys are distinct receivers, at least `n` receivers shared it, and an equal share
  is at most `joules_micro / n`; with no reconciliation, a receiver's share is at most the whole
  figure. Rounding up keeps it a bound in integer microjoules. Each reconciliation counted for
  the instance tightens it, and none raises it.
- **Its class is the figure's.** The bound is stated with the transmission figure's
  acquisition class and evidence (energy-measurement §2); the division adds no measurement and
  changes no relative uncertainty. Bounds of two instances, or of two classes, are never added.
- **No figure, no bound.** Where `energy` is `null` the verifier states no bound at all, never
  a bound of 0 (energy-measurement §2).
- **Keys are not receivers.** A receiver that reconciles under several keys is counted once
  for each and lowers the bound below its share. The count is a count of keys, and a verifier
  reports it as one. A relying party that needs a bound per receiver counts only keys it has
  confirmed (jwp-receipts §7.4) with the authority `reconciliation` under an origin it relies
  on to give that authority to one key per receiver, and reports that it did (§6.2 step 5,
  `sink_not_confirmed`).
- It is not the group's production energy: `joules_total` (jwp-receipts §2.4.1) and its
  objects' figures are read as jwp-receipts reads them, and never added to a transmission's.

## 8. Verification without a return path

### 8.1 Anchors

A sink on a bearer with no return path cannot retrieve a key log from an origin's location
(jwp-receipts §7.3, http-delivery §8.4): first-use retrieval is unavailable to it. It confirms
under anchors it already holds — logs provisioned in advance by its relying party (pinned), or
logs it retrieved earlier over another path (fetched, with the time it retrieved them). The
pinned-only authorities, and any authority registered for pre-emption, are confirmed only
under a pinned anchor that has not moved (jwp-receipts §7.4 step 6a), on this bearer as on any
other.

### 8.2 Logs that arrive on the bearer

A key log that reaches a sink over the bearer — in a file carousel, a delivery session, a
multicast track — is neither pinned nor fetched, whatever it holds. The sink:

- reads it as jwp-receipts §7.3 reads a log, and holds its revisions, each checked against its
  parent when §7.4 step 3 walks them, so a revocation or a rotation its origin sends over the
  bearer reaches a sink that has the origin anchored;
- **MUST NOT** anchor an origin from it (`anchor_on_bearer`): an item under an origin the sink
  has not otherwise anchored stays unconfirmed (`origin_not_anchored`). A trust anchor
  delivered over the bearer it authorises is not a trust anchor
  ([unidirectional-delivery](unidirectional-delivery.md) §3), for receipts as for pre-emption.

A revision on the bearer that its anchored line does not authorise — another root, a log
written by whoever controls the bearer — is no child of the trusted line (jwp-receipts §7.2
rule 7) and confirms nothing.

### 8.3 The procedure

Given the item to confirm (a group receipt with its object receipts, or a claim), the logs the
sink was provisioned with and the logs that arrived on the bearer:

1. verify the item — the group under jwp-receipts §3 steps 1 and 2 and each object under step
   5; a claim under §3.1 steps 1–4 — and stop with its reason if it fails;
2. anchor each provisioned log as pinned (jwp-receipts §7.3), holding its revisions; a log
   that does not read anchors nothing, with its reason;
3. read each log that arrived on the bearer as jwp-receipts §7.3 reads one and hold its
   revisions; report it `held` where its origin is anchored by step 2, and `anchor_on_bearer`
   otherwise. A log that does not read is held in no part, with its reason;
4. confirm the item under jwp-receipts §7.4 against every revision held and the anchors of
   step 2, and, for a transmission claim with an energy figure, its figure as a second item
   (§4.4).

The procedure touches no network and no clock; sinks holding the same bytes reach the same
verdicts, offline, on every platform. A confirmation describes the log as the sink holds it:
a revocation that has not reached it is not in it, and the head's `revision_hash` it reports
says how current that was.

## 9. Bearer mappings

### 9.1 What WAI fixes on every bearer (normative)

Where a bearer carries files or objects, WAI controls these bytes:

- **Envelopes.** Each object is one WAI envelope, carried whole as one file, object or segment
  of the bearer; its bytes are the ones jwp-receipts §2.1 hashes. The bearer's own framing —
  packets, forward error correction, an object's encoding for transport — is outside them, and
  a sink hashes the envelope it reconstructs.
- **Receipts and claims.** A group receipt and every claim — transmission and reconciliation
  claims among them — travel as the receipt files of [http-delivery](http-delivery.md) §8.1,
  under the same name relative to the objects' location (`rcpt/<link hash>.json`), with the
  same bytes and the same limits, and a sink reads each as §8.1 reads one. An object's receipts
  travel in its receipt index (http-delivery §8.2). On a bearer that carries tracks rather than
  files, the group and object receipts ride the receipts track
  ([moq-streaming-format](moq-streaming-format.md) §4.1); this revision defines no carriage of
  claims on a track, so claims travel as receipt files on whatever file path the sink has.
- **The declaration rides with the group.** A publisher that declares a transmission **SHOULD**
  send the transmission claim on the same bearer instance and in the same session as the
  group's receipts, so that a sink receives the declaration that covers what it received.
- **Key logs.** A key log a bearer carries is the document of jwp-receipts §7.2, at the path
  `/.well-known/wai-keys` relative to the origin it names, and anchors nothing (§8.2).
- **Reconciliation.** A sink sends its reconciliations, when it has a path, as receipt files;
  where the bearer's own reporting carries files or opaque payloads, it **MAY** carry them
  there. A reconciliation is the same claim whatever carried it.

The mappings below are **informative**: each says where these ride in the bearer's own
structures and what path back it defines.

### 9.2 FLUTE (RFC 6726)

Each envelope, receipt file and receipt index is one FLUTE file, named in the File Delivery
Table by its `Content-Location`, with `Content-Type` and, where the sender gives it,
`Content-MD5` (§3.4.2). The table admits further attributes (§3.4.2), and WAI defines none:
everything a sink checks is in the files. FLUTE is a unidirectional delivery service with no
feedback (§7.4), so a transmission over it is declared `unidirectional` unless another standard
adds a path back, and reconciliation goes over another path or none.

### 9.3 DVB multicast ABR (ETSI TS 103 769)

The multicast server carries each object as a transport object of FLUTE (Annex F) or ROUTE
(Annex H), and the gateway serves it to players over HTTP. Envelopes ride as the media
objects; receipt files, receipt indexes and key logs ride as the "other resources" a
`ResourceLocator` carousels in the same session (clause 10.2.3.14.3; ancillary objects, clause
8.3.4.4). Unicast repair (clause 9) and service reporting (clause 11: a JSON report posted to
`/dvb/mabr/reportingInformationInstance`) are paths back where the deployment has them; a
report's object-delivery event carries a status, not the object (Table 11.1.2.2-1), so a
reconciliation, which names objects, travels beside it as a receipt file. A deployment with
both paths declares `multicast`; one without, `unidirectional`. The integrity and authenticity
the specification adds (clause 12: content digests and HTTP message signatures) are the
gateway's checks of transport objects and change no WAI byte.

### 9.4 DVB-I (ETSI TS 103 770)

A service list signals the instances of a service — among them multicast transport streams
and DASH (clause 5.5.18) — and an identifier-based instance whose locator is an opaque URI
(clause 5.5.18.8). It carries no objects of its own and defines no path back. Where the service list gives an
instance a URI — an identifier-based locator, or a DASH presentation's address — a publisher's
`bearer_id` for that instance **SHOULD** be that URI, so a sink reading the list finds the
declaration by it.

### 9.5 ATSC 3.0 (A/331)

ROUTE carries envelopes as file-mode objects described by the Extended FDT, or in entity mode
(Annex A.3.3.2, A.3.3.3); receipt files, receipt indexes and key logs ride as locally cached
non-real-time files in the same ROUTE session, with relative `Content-Location` (clause
8.1.1.2), or inside a signed package (Annex A.3.3.5). A/331 requires its signalling tables to
be signed (clause 5.9; A/360:2026-08 clause 5.2.2); that signs the signalling, not the media
files, and is the broadcaster's statement, not the publisher's. Service usage reporting
(A/333:2026-04) reports consumption by service and interval, not by file or object, and is
unsigned; byte-range repair over broadband (A/331 clause 8.3) is a path back where the receiver
has broadband. A receiver with broadband sends reconciliations as receipt files; the broadcast
transmission is declared `unidirectional`, and the broadband path, where a group is also served
over it, is a `bidirectional` instance of its own.

### 9.6 3GPP MBMS and 5G multicast-broadcast (TS 26.346, TS 26.517)

MBMS download delivery carries each file over FLUTE with its own `Content-Location` (TS 26.346
clause 7.2); 5G multicast-broadcast user services carry objects by their object distribution
method, on the same download profile, in single, collection, carousel or streaming mode (TS
26.517 clause 6.2), and envelopes, receipt files, indexes and key logs ride as objects of the
session. File repair (TS 26.346 clause 9.3; TS 26.517 clause 6.2.4) is a path back. MBMS
reception reporting (TS 26.346 clause 9.4) lists each file received by its `fileURI`, with
`Content-MD5` where the table carried it, and is unsigned: it names files, not objects of a
group, and a reconciliation travels beside it. TS 26.517 defines no reception report, and
TS 26.502 leaves one for further study (clause 4.2.5). A session whose receivers report
declares `multicast`; one without a path back, `unidirectional`. A receiver of MBMS download
supports the Compact No-Code and Raptor schemes (TS 26.346 clause 7.2.2), which a schedule of such a
session states as `no-code` and `raptor` ([carousel](carousel.md) §4.1).

### 9.7 MoQ over multicast (`draft-ramadan-moq-multicast-02`)

The draft adds a root member `multicast` to a MoQ catalog, listing the multicast endpoints
its tracks are sent to (§4.1), with a MoQ unicast session first and unicast failover and
repair (§1.1, §6). A sink that holds the unicast session is reached `multicast` with a path
back, and one that only joined a multicast group is reached `unidirectional`.

**What changed since -00, and what it leaves a WAI track.** At -02 every multicast datagram
carries one MMTP packet, and an endpoint lists only tracks of packaging `mmtp` and the
`fec-repair` tracks that repair them; a track of another packaging reaches multicast through
an `mmtp` rendition of the same media, a separate track in its `altGroup` (§4.1, §5). A WAI
track is not of packaging `mmtp`, and WAI defines no MMTP rendition of an envelope
(`draft-ramadan-moq-mmt-02`, which defines that packaging, was not read), so at this revision
**no WAI track rides one of the draft's endpoints**, and the receipts track does not either.
What §9.1 fixes still holds of whatever carries the envelopes: a publisher that sends WAI
objects over a multicast group by other means declares that instance by its own `bearer_id`
(§4), and schedules it with a carousel schedule, whose RaptorQ entries are the FEC instances
of a MoQ catalog ([carousel](carousel.md) §8.3). The draft's own signed manifest records
(§7.2) are the draft's, beside the receipts; WAI reads nothing from them. No MoQ
working-group draft (`draft-ietf-moq-transport-23` among them) defines multicast at this
revision.

**Reading the endpoints.** What a sink of WAI does read is the list, to know which endpoints
a catalog offers and to refuse the ones the draft has a receiver ignore (§4.1). `multicast`
is an object whose `endpoints` is an array of at least one object, or the catalog offers none
(`endpoints_malformed`). Each endpoint is read in this order and **ignored**, with the first
that fails, the others standing:

| label | when |
|---|---|
| `endpoint_malformed` | The endpoint is not an object; `groupAddress` is not a string or `tracks` not an array of at least one object; `sourceAddress` or `protocol`, where present, is not a string; or `bandwidth`, where present, is not an integer from 0 to 2^53 − 1. |
| `endpoint_address` | `groupAddress`, or `sourceAddress` where present, is not an IP address; the two are of different families; or the group is not a multicast address of its mode: with a `sourceAddress` (source-specific), inside 232.0.0.0/8 or ff3*x*::/32; without one, inside 224.0.0.0/4 or ff00::/8 and outside those ranges. |
| `endpoint_mode` | `protocol` is neither `"ssm"` nor `"asm"`, or disagrees with whether `sourceAddress` is present. |
| `endpoint_port` | `port` is not an integer from 1 to 65,535. |
| `endpoint_packet_id` | A listed track's `name` is not a string, or its `packetId` is not an integer from 1 to 65,535 (0 is the sending entity's signalling flow). |
| `endpoint_track` | A listed track is not a track of the catalog, declares a namespace, or is neither of packaging `mmtp` nor a `fec-repair` track whose `source` is a track of packaging `mmtp`. |
| `endpoint_auth` | The endpoint carries `auth` and `multicast` does not, or the reverse; or it carries `auth` and no `bandwidth`. |

An endpoint that stands is a candidate, and no more: the draft has a receiver validate a
relay or a tunnel at the protocol layer before it uses one, with bounded attempts (§3.1), and
that is the receiver's own. The reference reads the list and joins nothing: it opens no
socket, resolves no name and reads no `networkSource`. A namespace a listed track declares
is refused outright, where the draft refuses one that differs from the catalog track's; the
reader is given a catalog, not the track it came on.

The reference reader is `carousel::moq_fec::read_endpoints` of `wai-rs`; its cases are in
[`live-conformance/carousel-moq-fec/`](../live-conformance/carousel-moq-fec/), and
`live-conformance/carousel_moq_fec_verify.py` reads them independently.

### 9.8 HbbTV (ETSI TS 102 796)

An HbbTV application reads files of a broadcast DSM-CC object carousel (ETSI TS 102 809
clause 7.1, ETSI TS 102 796 clause 7.2.2) and fetches over broadband (clause 7.3.2). V1.8.1
(HbbTV 2.0.5) adds WebAssembly for applications (clause A.3.28, Annex R), so a sink built for
WebAssembly runs inside an application. Envelopes, receipt files and key logs ride as carousel
files; the carousel is `unidirectional`, and the application's broadband path is the path back
for reconciliations. A key log carried in the carousel is not an anchor (§8.2): the anchor is
provisioned with the application, by its relying party. The carousel's own signing (ETSI TS
102 809 clause 9) is optional in HbbTV and signs the carousel, not the publisher's objects.

## 10. Reasons

The codes this extension adds, each with where it is raised:

| reason | raised at |
|---|---|
| `transmission_not_transmitted` | §4.2 rule 1 |
| `transmission_subject_mismatch` | §4.3 step 1 |
| `transmission_signer_mismatch` | §4.3 step 2 |
| `reconciliation_not_received` | §5.2 rule 1 |
| `reconciliation_bitmap_malformed` | §5.2 rule 2 |
| `reconciliation_subject_mismatch` | §5.3 step 1 |
| `reconciliation_by_publisher` | §5.3 step 2 |
| `reconciliation_leaf_count_mismatch` | §5.3 step 3 |
| `reconciliation_objects_not_held` | §5.3 step 4 |
| `reconciliation_root_mismatch` | §5.3 step 4 |
| `bearer_contradicted` | §6.2 steps 4 and 5, §6.5 |
| `bearer_not_declared` | §6.2 step 5, §6.4, §6.5 |
| `sink_not_confirmed` | §6.2 step 5 |
| `reconciliation_duplicate_sink` | §6.2 step 5 |
| `delivery_not_reconciled` | §6.4 |
| `delivery_exceeds_reconciled` | §6.4 |
| `anchor_on_bearer` | §8.2, §8.3 step 3 |

A group or object also raises the codes of jwp-receipts §3.3, a claim every code of jwp-receipts
§3.1 steps 1 to 5 and those of step 6 named in §4.3 and §5.3, and a confirmation the codes of
jwp-receipts §7.7.

## 11. Conformance

[`live-conformance/bearers/`](../live-conformance/bearers/) holds the corpus, written from fixed
seeds by `wai_bearer_vectors gen` as `vectors.json`. It has:

- **One receipt on every bearer**: one group and its object receipts, byte for byte, with a
  declaration of each class, verified by a sink holding the bytes; the object verdicts are the
  same in every case, and the group's bytes are checked equal across them.
- **Verdicts**: groups `published`, `transmitted` and `reconciled`; a group simulcast on two
  instances, each with its own count and bound; partial and whole reconciliations, a labelled
  group among them; a duplicate sink, joined; a relying party counting confirmed keys only.
- **Energy**: bounds before and after reconciliations arrive, an unmetered transmission with
  no bound, and a hardware-class figure.
- **Negative controls**, one for each reason of §10 that a verdict or a claim raises: a
  transmitted-only group presented as delivered; a partial reconciliation presented as delivered
  to a sink; a reconciliation over a leaf that is not the group's; one signed by the publisher's
  key; one whose objects are not held; a declaration over another group, one signed by another
  key, and two that contradict each other; a reconciliation over an undeclared instance; a
  sink whose bearer was not declared; and malformed bodies.
- **Offline**: confirmation under a pinned anchor with no network; a revocation that arrives on
  the bearer; a log forged on the bearer for a pinned origin; a log that arrives on the bearer
  for an origin not pinned (`anchor_on_bearer`); and a hardware-class transmission figure
  confirmed beside its declaration.

A conforming verifier gives every case the outcome, the reason and everything else the corpus
states. `wai_bearer_vectors verify` and the test `tests/bearer_receipts.rs` check that the file
regenerates byte for byte, that `wai-rs` gives every case its outcome, that every reason of §10
appears, and that §10 lists exactly the reference's codes. `live-conformance/bearer_verify.py`
is the second implementation, written from this text: it shares no code with `wai-rs`; it
verifies groups and objects with the JWP corpus's second implementation
(`jwp-conformance/jwp_verify.py`), claims through steps 1–5 with the claim corpus's
(`claim-conformance/claim_verify.py`), and confirmations with the key-discovery corpus's
(`signer-conformance/signer_verify.py`), and writes §4.3, §5.3, §6, §7 and §8 itself; and it
mutates copies of the corpus and requires every copy to fail.

## 12. Security and privacy considerations

- **A declaration is the publisher's word.** Nothing checks that a bearer instance exists or
  that its class is the one declared. A false `bidirectional` gains nothing here: no class of
  bearer makes a group delivered (§6.3).
- **A reconciliation is the sink's word** (§5.4). Keys are cheap; a party that wants a group to
  look widely received signs many reconciliations. That raises `sinks` and `whole` and lowers
  the bound, and both are reported as counts of keys (§7). A relying party that needs more
  counts confirmed keys only.
- **Replay.** A reconciliation names the group by its link hash, so it cannot be moved to
  another group; within one group a second one of a key adds nothing (§6.2 step 5).
- **What a sink discloses.** A sink on a broadcast bearer is unobserved:
  [unidirectional-delivery](unidirectional-delivery.md) §2's property is that the source learns
  nothing. A reconciliation gives that up for the groups it names, to the distributor that
  receives it. Reconciling is part of the delivery service a distributor operates over WAI, and
  this extension sets no consent rule of its own for it. Where a regime asks the distributor
  for a lawful basis, the distributor records it as a `lawful-basis` claim
  ([jwp-receipts](jwp-receipts.md) §2.4.6). A sink **MAY** sign each reconciliation with a
  fresh `did:key`, which unlinks its reconciliations and leaves each group's count unchanged.
- **A bearer that lies about keys.** A log on the bearer anchors nothing (§8.2), so whoever
  controls the bearer can withhold revisions — a revocation among them — but cannot add a key
  to an anchored origin. A sink that has had no path for long holds a stale log, and its
  confirmation reports the head it used.

## 13. The compact return profile

A path back from a sink or a node may carry only a few bytes in each message: a radio frame, a
text message, a satellite uplink. A reconciliation (§5) is a JSON claim that writes its group's
link hash, its root, its signer's key and its signature in hexadecimal, beside the instance's URI;
a holdings record ([holdings](holdings.md) §4) names its holder and each group by 32 bytes. This
profile writes both records in a binary form that names by short references what the receiver
already holds — the group, the bearer instance, the signer — and carries a message too long for
one frame in fragments, with a check over the whole message.

The compact form is an encoding, never a statement of its own. A receiver expands a compact
record, against what it holds, into the record's own bytes and verifies that record by its own
text; the signature a compact record carries is the record's. Nothing here changes what a
reconciliation or a holdings record states, how either is verified, or what a verifier derives
from it (§6, holdings §5).

### 13.1 Terms

- **Path**: what carries messages from a **sender** (a sink, or a node) to a **receiver** (the
  distributor that reconciles, or a node that gathers for it). Its **frame** is the most bytes
  one of its messages carries.
- **Context**: what the receiver holds that a compact record names. Nothing a compact record
  carries adds to it.
  - **Groups**: group receipts that pass jwp-receipts §3 steps 1 and 2, each with the object
    receipts held under it that pass §3 step 5 against it, and the `bearer_id` of each instance
    of the group the receiver holds a declaration of (§4).
  - **Signers**: keys, each with a `signer_id`: keys the receiver confirmed under jwp-receipts
    §7, or keys its senders enrolled with it.
- **Compact record**: a reconciliation (§13.3) or a holdings record (§13.4) in this profile's
  form, at most 65,531 bytes. **Message**: a compact record followed by its **check**, the first 4
  bytes of SHA-256 over the compact record. **Fragment**: one frame's part of a message (§13.6).

A fixed-size integer is unsigned and big-endian.

### 13.2 Uints, instants and references

- A **uint** is an unsigned integer in LEB128: seven bits a byte, least significant first, the
  high bit set in every byte but the last. It is written in the fewest bytes, so a last byte of
  0x00 follows no other byte, and its value is at most 2^53 − 1, so it has at most 8 bytes.
- An **instant** is a uint of seconds since 1970-01-01T00:00:00Z, leap seconds not counted, at
  most 253,402,300,799 (9999-12-31T23:59:59Z). It stands for the RFC 3339 date-time of that
  second written `YYYY-MM-DDTHH:MM:SSZ`, with `T` and `Z` in capitals, no fraction and a second
  below 60. A date-time written in any other way has no instant.
- The **reference** of a value is the first *n* bytes of SHA-256 over it: a group's is 8 bytes
  over its link hash (32 bytes); a bearer instance's, 4 bytes over its `bearer_id` in UTF-8; a
  signer's, 8 bytes over its key (32 bytes).
- A reference **resolves** to the one value of its kind in the context that has it: a group
  among the groups; a bearer instance among the instances of the group the record names; a
  signer among the signers — a key with its `signer_id` for a reconciliation, a key for a
  holdings record, which names no `signer_id`. Values that are equal are one value. A
  reference that no value has is refused `compact_reference_unknown`, and one that more than
  one value has, `compact_reference_ambiguous`: neither is resolved by choosing.

### 13.3 A compact reconciliation

| size | field | meaning |
|---|---|---|
| 1 | `kind` | 0x01 |
| 1 | `form` | below |
| 8 | `group` | the reference of the group: the claim's `subject` |
| 4 | `bearer` | the reference of the bearer instance: the body's `bearer_id` |
| uint | `seq` | the claim's `seq` |
| uint | `issued_at` | the claim's `issued_at`, as an instant (§13.2) |
| 32, 32 + uint + *n*, or 8 | `signer` | by the signer form, below |
| 32 or 0 | `parent` | the claim's `parent_receipt_hash`, where `form` says the claim has one |
| ⌈`leaf_count` / 8⌉ or 0 | `received` | the bitmap of §5.1, where `form` says the reconciliation is partial; `leaf_count` is the group's |
| 64 | `sig` | the claim's `sig` |

`form` is read by its bits:

| bits | meaning |
|---|---|
| `form & 0x03` | the body's `bearer`: 0 `bidirectional`, 1 `multicast`, 2 `unidirectional` |
| `form & 0x04` | set: **whole**, every object of the group received, and no `received` follows; clear: **partial** |
| `(form >> 3) & 0x03` | the signer form: 0, the key (32 bytes), whose Ed25519 `did:key` (jwp-receipts §7.1) is the `signer_id`; 1, the key, then a uint *n* and the `signer_id` in *n* bytes of UTF-8; 2, the reference of the signer (8 bytes) |
| `form & 0x20` | set: a `parent` follows; clear: `parent_receipt_hash` is `null` |
| `form & 0xc0` | 0 |

A reader reads exactly the bytes it is given, field by field in the order of the table, and
refuses them `compact_malformed` when they are more than 65,531 bytes, end before a field or go
on after `sig`, or when:

1. `form` sets a bit of 0xc0, or names the bearer 3 or the signer form 3;
2. a uint breaks §13.2, or `issued_at` is past its bound;
3. in the signer form 1, the `signer_id` is not UTF-8, or is the key's own `did:key`, which is
   the signer form 0;
4. a partial `received` sets no bit, sets a bit at or past `leaf_count`, or sets every bit below
   it, which is the whole form.

It resolves `group` as it reads it, since `received`'s length is the group's; then `bearer` among
that group's instances; and, in the signer form 2, `signer` (§13.2).

Its **expansion** is the reconciliation claim in its canonical form (jwp-receipts §2.4.3), with:

- `kind` `claim`, `class` `reconciliation`, `subject_type` `receipt`, and `subject` the link hash
  of the group resolved;
- `seq`, `issued_at` (the instant's date-time), `signer_pubkey`, `signer_id`,
  `parent_receipt_hash` and `sig` from the fields;
- a body of `bearer` from `form`, `bearer_id` the instance resolved, `leaf_count` the group's,
  `attests` `received`, and:
  - whole: `received` the bitmap that sets every bit below `leaf_count`, and `received_root` the
    group's `root_hash`;
  - partial: `received` as carried, and `received_root` the root jwp-receipts §2.2 computes over
    the leaves of the object receipts the context holds at its set bits, in increasing order, each
    leaf in its object receipt's form. A set bit at which the context holds no object receipt is
    refused `compact_objects_not_held`.

The expansion is then verified as every reconciliation is: jwp-receipts §3.1, and §5 here. A
compact record whose bytes were changed, where it still reads, expands to a claim its signer did
not sign.

### 13.4 A compact holdings record

| size | field | meaning |
|---|---|---|
| 1 | `kind` | 0x02 |
| 1 | `form` | 0: the holder's key follows (32 bytes); 1: the reference of the holder follows (8 bytes) |
| 32 or 8 | `holder` | the holder |
| uint | `as_of_ms` | the record's `as_of_ms` |
| uint | `window_ms` | its `expires_ms` less its `as_of_ms` |
| uint | `n` | its entries' count, at most 2^32 − 1 |
| … | `entries` | `n` entries, below, in the record's order |
| 64 | `sig` | the record's `sig` |

An entry:

| size | field | meaning |
|---|---|---|
| 1 | `form` | `form & 0x01` set: every object of the group (holdings §4.2's form 1), and no `held` follows; `form & 0x02` set: the group by reference; every other bit 0 |
| 8, or 32 + uint | `group` | by reference: the reference of the group, whose `leaf_count` is the group's; else the group's link hash, then its `leaf_count` as a uint |
| ⌈`leaf_count` / 8⌉ or 0 | `held` | the bitmap of holdings §4.2, in its form 0 |

A reader reads exactly the bytes it is given, in the order of the tables, resolving each
reference as it reads it, and refuses them `compact_malformed` when they are more than 65,531
bytes, end before a field or go on after `sig`, or when a `form` is not one the tables give, a
uint breaks §13.2, or `n` is past its bound. Its **expansion** is the holdings record of holdings
§4.1: `WHD1`, version 1, the holder's key, `as_of_ms`, `as_of_ms` + `window_ms`, `n`, each
entry's link hash, `leaf_count`, form and `held`, and `sig`. The expansion is then read as every
holdings record is, by holdings §4.4, and holdings §5 applies to it.

### 13.5 Writing a record compactly

The compact form of a record **against a context** — what its sender knows its receiver holds —
is the one the rules below give, and its expansion against that context is the record, byte for
byte. A reader takes every form: a value written inline expands as its reference would.

- **A reconciliation** has a compact form when it reads under jwp-receipts §3.1 steps 1 and 2 as
  a claim of class `reconciliation` without the hybrid members of
  [pq-signatures](pq-signatures.md) §3.1, its text is its canonical form, its `issued_at` has an
  instant, and its expansion against the context is that record: the context holds its group
  and, for that group, its instance; its `leaf_count` is the group's; and its `received` and
  `received_root` are ones §13.3 reads and derives. Its signer is written by
  reference where the context holds its key with its `signer_id` and the reference resolves to
  them, else in the form 0 where its `signer_id` is its key's `did:key`, else in the form 1.
- **A holdings record** has a compact form when it reads under holdings §4.4, its signature
  verifying. Its holder is written by reference where the context holds its key and the reference
  resolves to it, and each entry's group by reference where the context holds that group with the
  entry's `leaf_count` and the reference resolves to it; each is written inline otherwise.

A record that has no compact form is refused `compact_not_encodable`, and travels in its own
form. A sink that sends its reconciliations over a path whose frame is small **SHOULD** sign them
with an `issued_at` that has an instant: to the second, in UTC.

### 13.6 Fragments

| size | field | meaning |
|---|---|---|
| 1 | `message` | the sender's number for the message, the same in each of its fragments |
| 1 | `index` | the fragment's position in the message, from 0 |
| 1 | `count` | the message's fragments, 1 to 255 |
| … | `data` | at least one byte of the message |

A message is at most 65,535 bytes. A sender cuts it, in order, into fragments of the path's frame,
the last holding what remains: the fragments' `data`, in increasing `index`, are the message. It
numbers its messages on one path modulo 256, and does not use a number again while a fragment
under it may still arrive. A path whose frame is 3 bytes or fewer carries no fragment, and a
message that would need more than 255 fragments of a path's frame is not sent over that path.

### 13.7 Reassembly

The steps below are defined over a set of fragments taken as one message's. A receiver forms that
set from the fragments it receives, by their sender, as the path addresses it, and by `message`;
how it forms the set is not a step, and refuses nothing. A set formed by `message` holds no
fragment under another number, and step 2 refuses one in a set formed otherwise. Fragments that
are the same bytes are one fragment of the set, so a fragment the path delivers twice is held
once. Given a message's fragments, in any order, a receiver checks, in this order:

1. each fragment has at least 4 bytes, a `count` of at least 1 and an `index` below its `count`
   (`fragment_malformed`);
2. each has the first's `message` and `count` (`fragment_foreign`);
3. no two that differ have one `index` (`fragment_repeated`);
4. there are `count` of them (`fragment_missing`); a message of which no fragment is held is
   missing;
5. their `data`, in increasing `index`, the message, is at most 65,535 bytes
   (`fragment_malformed`);
6. the message has more than 4 bytes, and its last 4 are the check over the bytes before them
   (`fragment_check_failed`).

The bytes before the check are the compact record, read by its `kind`: §13.3 for 0x01, §13.4 for
0x02, and `compact_malformed` for any other.

Fragments arrive in any order and are placed by their `index`. A fragment placed at a position
other than the one it was cut from — its `index` changed, or the data of two fragments exchanged —
is a **reordered** fragment. Where the headers still show a whole message, the check refuses the
message it is in (step 6), as it refuses a fragment of another message that carries this
message's `message` and `count`: steps 2 to 4 find what the headers show, and step 6 what they do
not.

### 13.8 Aggregated measurement on a small frame

A report of [telemetry-aggregation](telemetry-aggregation.md), a DAP report, is not a record of
this profile, and this profile never cuts one into fragments. A sink uploads each report whole to
the leader (telemetry-aggregation §5), and a report has no shorter form: its input shares are
encrypted to the aggregators. A task's **floor** is the length of its longest report. A sink
sends a task's reports only over a path that carries one whole, so a path whose frame is below a
task's floor carries none of its reports. Every report of a task of measures 1 to 4 of
telemetry-aggregation §3 has one length, its floor:

| measure | floor, bytes |
|---|---|
| 1 `outcomes` | 552 |
| 2 `stalls` | 824 |
| 3 `durations` | 2,664 |
| 4 `start_time` | 648 |

A sink whose every path is below a task's floor holds its reports until it has a path that
carries them, or gives them, over a short link, to a **node** that has one — a receiver's cache,
or a box that holds a carousel for the receivers near it. The node uploads each report as it
received it. It learns of each report its id, its time, its length and its task, as each
aggregator does (telemetry-aggregation §10), and which neighbour gave it, and nothing of its
measurement. A node **MAY** carry its neighbours' messages of this profile, or the records they
expand to, over its own path in the same way: a record a node carries is its sender's, unchanged,
and the node signs nothing of it.

### 13.9 Reasons

The codes this profile adds, each with where it is raised:

| reason | raised at |
|---|---|
| `compact_malformed` | §13.3, §13.4, §13.7 |
| `compact_reference_unknown` | §13.2 |
| `compact_reference_ambiguous` | §13.2 |
| `compact_objects_not_held` | §13.3 |
| `compact_not_encodable` | §13.5 |
| `fragment_malformed` | §13.7 steps 1 and 5 |
| `fragment_foreign` | §13.7 step 2 |
| `fragment_repeated` | §13.7 step 3 |
| `fragment_missing` | §13.7 step 4 |
| `fragment_check_failed` | §13.7 step 6 |

An expansion also raises the codes of its record's own verification: those of jwp-receipts §3.1
and §10 here for a reconciliation, and holdings §7's for a holdings record.

### 13.10 Conformance

[`live-conformance/compact-return/`](../live-conformance/compact-return/) holds the corpus,
written from fixed seeds by `wai_compact_return_vectors gen` as `vectors.json`. It has:

- **Round trips**: reconciliations whole and partial, over each bearer class, in each signer form,
  with and without a parent, a group of labelled leaves and a bitmap whose last byte is part used
  among them; and holdings records with their holder and groups by reference and inline. Each
  case carries the record, the context and the compact record, written from the record and
  expanded back to it, byte for byte, and the record's verdict under its own text.
- **Expansions**: every form a reader takes, a value the receiver holds written inline among
  them; a compact record with a byte changed, which expands and is refused by its record's own
  signature; one negative control for each rule of §13.3 and §13.4 but the bound of 65,531
  bytes, which both implementations check themselves; references unknown and ambiguous, two
  bearer instances that share one reference among them; a bearer instance the receiver holds for
  other groups and not for the record's, which is unknown; a holder's key held under two
  `signer_id`s, which resolves, since a holdings record names no `signer_id`; and a partial
  reconciliation against a receiver that holds no object receipt.
- **Encodings**: records with no compact form, each refused, a reconciliation whose `leaf_count` is
  2^53 − 1 beside a bitmap of one byte among them.
- **Messages and reassemblies**: compact records cut into frames of several sizes, one fragment
  among them, and reassembled in order and in other orders, and with a fragment delivered twice,
  byte for byte, which is held once; and a missing fragment, a repeated one (other data at its
  `index`, and a fragment relabelled to another's `index`), a reordered one (data exchanged,
  indices exchanged), a foreign one (another number, another count, and the same header from
  another message), a changed byte, and malformed fragments.

A conforming verifier gives every case the outcome, the reason and everything else the corpus
states. `wai_compact_return_vectors verify` and the test `tests/compact_return.rs` check that the
file regenerates byte for byte, that `wai-rs` gives every case its outcome, that every reason of
§13.9 appears, that §13.9 lists exactly the reference's codes, and that §13.8's floors are the
lengths of the reports in telemetry-aggregation's corpus, read with the reference's DAP reader.
`live-conformance/compact_return_verify.py` is the second implementation, written from this text:
it shares no code with `wai-rs`; it reads groups, objects and leaves with the JWP corpus's second
implementation (`jwp-conformance/jwp_verify.py`), claims with the claim corpus's
(`claim-conformance/claim_verify.py`), §5.3 with `bearer_verify.py`, holdings records with
`holdings_verify.py` and DAP reports with `telemetry_aggregate_verify.py`, and writes §13.2 to
§13.8 itself; it checks the floors against telemetry-aggregation's own table and corpus; and it
mutates copies of the corpus and requires every copy to fail, and drops each of its own checks in
turn and requires the corpus to catch the weakened verifier.

### 13.11 Security and privacy considerations

- **The compact form carries no trust of its own.** It carries its record's signature, and the
  receiver verifies the expansion by the record's own text. A reference that resolved to another
  value would expand to another record, which that signature does not verify.
- **The check is not a signature.** Its four bytes of SHA-256 find what a fragment's header does
  not show — a fragment misplaced, or mixed in from another message under the same header, and a
  byte changed on the path — and authenticate nothing. Anyone on a path can make a message whose
  check holds: what it expands to is refused unless its signer signed it.
- **What a reference discloses.** A reference names what the receiver holds, and says no less
  than the record it stands for: anyone who holds the group receipts resolves a group's. A signer
  by reference links a sender's messages as its key does. A sink that signs each reconciliation
  with a fresh `did:key` (§12) sends its key inline, in the signer form 0.
- **Bounded work.** A message is at most 65,535 bytes in at most 255 fragments, a compact record is
  read once, in order, and resolving a reference is a lookup. A receiver **SHOULD** bound how long
  it holds the fragments of a message that has not completed; this profile sets no bound. A writer
  sizes nothing by a reconciliation's own `leaf_count` before it has found it to be the group's
  (§13.5): a record a node carries for a neighbour (§13.8) can state a `leaf_count` of 2^53 − 1
  beside a bitmap of one byte and still read under jwp-receipts §3.1 steps 1 and 2.