wai: an ad decision's consent signal and supply chain, bound into what the decider signs #641

Merged

dcharlot merged 2 commits from wai/ad-consent-supply-chain into main 2026-11-05 10:48:19 -05:00

Conversation 0 Commits 2 Files changed 45 +8399 -104

dcharlot commented 2026-11-05 04:27:10 -05:00

Owner

Copy link

What this is

A break-form wai.video.ssai receipt of version 2 states the consent signal its ad decision was made under and the supply chain of each impression, and signs both. A live-ads policy of version 3 can mark a room as directed to children. The stitched pod-input record carries the same consent signal.

Merge order. Stacked on #633, merge after it. #633 is wai/one-way-delivery. The two merge cleanly, but together they do not compile without this branch's second commit: one-way's impressions corpus builds a stitched_presentation::PodInput, and this branch adds a field to it. Both sit on #632's commit, 946f3beda, which moves changelog entries into wai/changes/ and the conformance workflow's lists into step files, so #632 merges before either. Until they merge, this pull request's diff also shows their changes.

What it carries. Two commits on wai/one-way-delivery's converted commit, 793ed1f2d:

• d6073e200: the change of wai/ad-consent-supply-chain (44d5f2264..110c53553) in #632's layout. Its message lists the source commits. The branch's changelog entry is a file of wai/changes/. Its block of wai/.gitattributes lines, for the live-ads supply files, sits just before the splat block instead of at the end of the file. A per-directory .gitattributes was not possible, because live_ads_verify.py and tests/live_ads.rs refuse any extra file in the corpus's directory. The live-ads and stitched-presentation steps already run these corpora, so the branch adds no step file. Every other file is as the source branch has it.
• f634e9ab1: the impressions corpus that one-way adds builds its records with consent: None. Each stays a version-1 record with the bytes it had.

What it defines

The consent signal (live-ads §8.6). A receipt of version 2 states:

• the Global Privacy Platform string the player gave with its request for the asset list, byte for byte;
• the sections that apply;
• a child-directed flag.

These are three of the members OpenRTB 2.6 gives an ad request's Regs. The receipt's rules hold the string to the URL-safe characters the GPP string's text lists, with its header and every section present, and hold the sections to the string. §8.6 says what each party does with the signal:

• the player gives the string as it holds it, and never writes or alters one;
• the decider states it byte for byte, and passes it unchanged in every request it makes to fill the break;
• the decider marks every such request as directed to children when the policy or the request does;
• no party reads consent from an empty string, or age from a flag of 0;
• neither the decider nor a verifier uses either to identify a viewer or to link one viewer's receipts;
• a verifier does not decode the string's sections. A receipt that verifies shows what the decider stated it was given and passed on, not that the viewer gave it or that any party honoured it.

A GPP string links what carries it (live-ads §12, stitched-presentation §11). A consent tool makes the string for a viewer, not for one request, so a receipt or a stitched record whose string is not empty can be linked through it to every other that carries the same string, by whoever holds them. The string is in the signed bytes, so it cannot be stripped from a receipt that stays verifiable. The rule against linking binds the decider and the verifier only.

The supply chain of each impression (§8.7). In supply_chains, the receipt states one entry for each impression: the SupplyChain object (OpenRTB 2.6 §3.2.25 and §3.2.26) of the request whose answer gave the decider that impression's candidate, or null. Each node's entry gives:

• its advertising system's domain, its seller id and its payment flag;
• the SHA-256 of that system's sellers file (Sellers.json 1.0);
• the SHA-256 of the inventory owner's authorised-sellers file (ads.txt 1.1, or app-ads.txt 1.0 for an app).

A verifier that holds those files checks each node against them. The node must be listed under its seller id in its system's sellers file. It must be authorised in the owner's file: DIRECT for the first node of a complete chain, and DIRECT or RESELLER for the others. A part whose file the verifier does not hold is stated unchecked. WAI carries the published object and its references, and defines no supply-chain scheme of its own.

How the files read (§8.7). An authorised-sellers file is read by the stated reading of ads.txt 1.1 §3.2 to §3.5. A sellers file is UTF-8 with no byte order mark, and a JSON text within limits RFC 8259 leaves to a reader:

• its arrays and objects nest at most 64 deep;
• the members read (sellers, seller_id, seller_type) are not given twice;
• the member names and strings read escape no lone surrogate.

The rest of the file is read by the grammar alone, and its numbers are never converted.

Signed. A receipt of version 2 signs under wai:video-ssai-break-receipt 0x02, with the consent signal and the chains in the impressions' order, between its impressions and its signer (§8.4). So a receipt whose string, sections, flag or chains changed after signing fails its signature, and so does one whose chains moved to other impressions. A receipt of version 1 keeps its bytes and its identity, and reads as before.

A policy of version 3 (§3.1) adds an audience whose bit 0, child, marks the room as directed to children. Under it every receipt is of version 2 (request_terms_absent), and every receipt is child-directed when the policy says so (child_directed_unset). Step 14 checks each chain against the supply files the verifier holds (supply_file_malformed, supply_seller_unlisted, supply_seller_unauthorised). A receipt's own rules gain consent_invalid and supply_chain_invalid.

The stitched pod-input record (stitched-presentation §4.7). WSI1 of version 2 carries the same consent signal after its ads, held to live-ads §8.6's rules, with the signer in the decider's place. A shared record, which every viewer is shown, carries no viewer's string. wai_stitched_presentation sign-pod writes a record of version 2 from a draft's consent.

Breaking: live_ads::corpus::generate and verify give and take each file of the corpus as bytes, since a supply file need not be UTF-8. These public structs gain members: SsaiBreakReceipt::terms, AdPolicy::audience, live_ads::Input::supply_files, ReceiptFacts::terms, PodInput::consent and RecordFacts::consent. The fault and reason enums gain the new variants. The entry file names each.

The reference and the independent verifiers

The reference. The wai_video_ssai module, its new terms part, and the live_ads and stitched_presentation modules of wai-rs. Their unit tests and tests/live_ads.rs and tests/stitched_presentation.rs check that:

• every file of each corpus regenerates byte for byte from its fixed seeds, and no other file is there;
• wai-rs gives every room, record and claim its stated outcome and facts;
• each extension's reason table lists exactly the reference's codes.

The corpora.

• live-conformance/ads/ gains a room under a policy of version 3, whose receipts state a GPP string with two ads sold through two complete chains, checked against two sellers files and an app-ads.txt. It also gains:
  • a child-directed request with no string, through an incomplete chain left unchecked;
  • a room directed to children;
  • a chain two impressions share, authorised only when each of §8.7's reading rules is applied;
  • receipts whose string, flag, chain or order of chains changed after signing, each refused bad_signature;
  • a control for each rule of §8.2's carriage of version 2, of §8.6 and of §8.7;
  • a control for each way a supply file fails to read, or to list or authorise a node.
• The supply files are files of the corpus, read as bytes and kept from line-ending conversion; one is not UTF-8.
• live-conformance/stitched/ gains consent: two records of version 2, one whose string changed after signing (bad_signature), a shared record carrying a viewer's string, and a record stating a section with no string (each pod_input_malformed). Every earlier vector keeps its bytes.

The independent verifiers. live_ads_verify.py and stitched_presentation_verify.py are written from the extensions' text and share no code with wai-rs. They read the request terms, the sellers files and the authorised-sellers files themselves, and require every mutated copy of their corpora to fail.

How it was verified

This stack, at f634e9ab1.

• Locally (git and Python checks only): scripts/wai-conformance-lists.py selftest and check, scripts/wai-conformance-lists-selftest.sh, scripts/check-changelog-fragment.py against main, scripts/changelog-assemble.py --check and scripts/changelog-fragments-selftest.sh all pass. Both rebases, onto 946f3beda and onto one-way's commit, were clean and left every file's change as the conversion first made it.
• On a Linux x86_64 build host:
  • in wai/wai-rs, cargo check --locked --no-default-features --tests under the derived WAI_FEATURES, and with each of impression_aggregate, stitched_presentation, live_ads, receipt_ledger, opportunity_report and video_ssai alone, and with one-way's and this branch's features together;
  • the impression-aggregates, receipt-ledger, live-ads and opportunity-report steps, as CI runs them, through scripts/wai-conformance-lists.py run --only: all four pass, so the impressions corpus regenerates byte for byte and its Python verifier passes;
  • the stitched-presentation step's lines, run by hand after compiling the wai_stitched_presentation binary that the workflow compiles first: its library tests and frame tests, tests/stitched_presentation.rs, the binary's vectors verify and stitched_presentation_verify.py. All pass. The step's last line, a node --test of joule-moq-web's ad page, was left out: that host has no node, and neither branch changes joule-code/.
• With the other converted branches. This branch, stacked as it is, merges without conflict with each of the other branches converted to #632's layout (by git merge-tree). Merging all of them in forward, reverse and a mixed order gives one tree. On the build host, that tree passes these runs: cargo check --tests under the derived WAI_FEATURES and under WAI_PQ_FEATURES; cargo check --tests of quickstart,app; the catalogue's library tests; and the wai binary's unit tests.

On the CI hosts. Results on the CI runners come from this pull request's own CI run. None of the runs above is a CI result.

🤖 Generated with Claude Code

## What this is A break-form `wai.video.ssai` receipt of version 2 states the consent signal its ad decision was made under and the supply chain of each impression, and signs both. A live-ads policy of version 3 can mark a room as directed to children. The stitched pod-input record carries the same consent signal. **Merge order.** Stacked on #633, merge after it. #633 is `wai/one-way-delivery`. The two merge cleanly, but together they do not compile without this branch's second commit: one-way's impressions corpus builds a `stitched_presentation::PodInput`, and this branch adds a field to it. Both sit on #632's commit, 946f3beda, which moves changelog entries into `wai/changes/` and the conformance workflow's lists into step files, so #632 merges before either. Until they merge, this pull request's diff also shows their changes. **What it carries.** Two commits on `wai/one-way-delivery`'s converted commit, 793ed1f2d: - d6073e200: the change of `wai/ad-consent-supply-chain` (44d5f2264..110c53553) in #632's layout. Its message lists the source commits. The branch's changelog entry is a file of `wai/changes/`. Its block of `wai/.gitattributes` lines, for the live-ads supply files, sits just before the splat block instead of at the end of the file. A per-directory `.gitattributes` was not possible, because `live_ads_verify.py` and `tests/live_ads.rs` refuse any extra file in the corpus's directory. The live-ads and stitched-presentation steps already run these corpora, so the branch adds no step file. Every other file is as the source branch has it. - f634e9ab1: the impressions corpus that one-way adds builds its records with `consent: None`. Each stays a version-1 record with the bytes it had. ## What it defines **The consent signal** (live-ads §8.6). A receipt of version 2 states: - the Global Privacy Platform string the player gave with its request for the asset list, byte for byte; - the sections that apply; - a child-directed flag. These are three of the members OpenRTB 2.6 gives an ad request's `Regs`. The receipt's rules hold the string to the URL-safe characters the GPP string's text lists, with its header and every section present, and hold the sections to the string. §8.6 says what each party does with the signal: - the player gives the string as it holds it, and never writes or alters one; - the decider states it byte for byte, and passes it unchanged in every request it makes to fill the break; - the decider marks every such request as directed to children when the policy or the request does; - no party reads consent from an empty string, or age from a flag of 0; - neither the decider nor a verifier uses either to identify a viewer or to link one viewer's receipts; - a verifier does not decode the string's sections. A receipt that verifies shows what the decider stated it was given and passed on, not that the viewer gave it or that any party honoured it. **A GPP string links what carries it** (live-ads §12, stitched-presentation §11). A consent tool makes the string for a viewer, not for one request, so a receipt or a stitched record whose string is not empty can be linked through it to every other that carries the same string, by whoever holds them. The string is in the signed bytes, so it cannot be stripped from a receipt that stays verifiable. The rule against linking binds the decider and the verifier only. **The supply chain of each impression** (§8.7). In `supply_chains`, the receipt states one entry for each impression: the `SupplyChain` object (OpenRTB 2.6 §3.2.25 and §3.2.26) of the request whose answer gave the decider that impression's candidate, or `null`. Each node's entry gives: - its advertising system's domain, its seller id and its payment flag; - the SHA-256 of that system's sellers file (*Sellers.json* 1.0); - the SHA-256 of the inventory owner's authorised-sellers file (*ads.txt* 1.1, or *app-ads.txt* 1.0 for an app). A verifier that holds those files checks each node against them. The node must be listed under its seller id in its system's sellers file. It must be authorised in the owner's file: `DIRECT` for the first node of a complete chain, and `DIRECT` or `RESELLER` for the others. A part whose file the verifier does not hold is stated unchecked. WAI carries the published object and its references, and defines no supply-chain scheme of its own. **How the files read** (§8.7). An authorised-sellers file is read by the stated reading of *ads.txt* 1.1 §3.2 to §3.5. A sellers file is UTF-8 with no byte order mark, and a JSON text within limits RFC 8259 leaves to a reader: - its arrays and objects nest at most 64 deep; - the members read (`sellers`, `seller_id`, `seller_type`) are not given twice; - the member names and strings read escape no lone surrogate. The rest of the file is read by the grammar alone, and its numbers are never converted. **Signed.** A receipt of version 2 signs under `wai:video-ssai-break-receipt` 0x02, with the consent signal and the chains in the impressions' order, between its impressions and its signer (§8.4). So a receipt whose string, sections, flag or chains changed after signing fails its signature, and so does one whose chains moved to other impressions. A receipt of version 1 keeps its bytes and its identity, and reads as before. **A policy of version 3** (§3.1) adds an `audience` whose bit 0, **child**, marks the room as directed to children. Under it every receipt is of version 2 (`request_terms_absent`), and every receipt is child-directed when the policy says so (`child_directed_unset`). Step 14 checks each chain against the supply files the verifier holds (`supply_file_malformed`, `supply_seller_unlisted`, `supply_seller_unauthorised`). A receipt's own rules gain `consent_invalid` and `supply_chain_invalid`. **The stitched pod-input record** (stitched-presentation §4.7). `WSI1` of version 2 carries the same consent signal after its ads, held to live-ads §8.6's rules, with the signer in the decider's place. A shared record, which every viewer is shown, carries no viewer's string. `wai_stitched_presentation sign-pod` writes a record of version 2 from a draft's `consent`. **Breaking:** `live_ads::corpus::generate` and `verify` give and take each file of the corpus as bytes, since a supply file need not be UTF-8. These public structs gain members: `SsaiBreakReceipt::terms`, `AdPolicy::audience`, `live_ads::Input::supply_files`, `ReceiptFacts::terms`, `PodInput::consent` and `RecordFacts::consent`. The fault and reason enums gain the new variants. The entry file names each. ## The reference and the independent verifiers **The reference.** The `wai_video_ssai` module, its new `terms` part, and the `live_ads` and `stitched_presentation` modules of `wai-rs`. Their unit tests and `tests/live_ads.rs` and `tests/stitched_presentation.rs` check that: - every file of each corpus regenerates byte for byte from its fixed seeds, and no other file is there; - `wai-rs` gives every room, record and claim its stated outcome and facts; - each extension's reason table lists exactly the reference's codes. **The corpora.** - `live-conformance/ads/` gains a room under a policy of version 3, whose receipts state a GPP string with two ads sold through two complete chains, checked against two sellers files and an app-ads.txt. It also gains: - a child-directed request with no string, through an incomplete chain left unchecked; - a room directed to children; - a chain two impressions share, authorised only when each of §8.7's reading rules is applied; - receipts whose string, flag, chain or order of chains changed after signing, each refused `bad_signature`; - a control for each rule of §8.2's carriage of version 2, of §8.6 and of §8.7; - a control for each way a supply file fails to read, or to list or authorise a node. - The supply files are files of the corpus, read as bytes and kept from line-ending conversion; one is not UTF-8. - `live-conformance/stitched/` gains `consent`: two records of version 2, one whose string changed after signing (`bad_signature`), a shared record carrying a viewer's string, and a record stating a section with no string (each `pod_input_malformed`). Every earlier vector keeps its bytes. **The independent verifiers.** `live_ads_verify.py` and `stitched_presentation_verify.py` are written from the extensions' text and share no code with `wai-rs`. They read the request terms, the sellers files and the authorised-sellers files themselves, and require every mutated copy of their corpora to fail. ## How it was verified **This stack, at f634e9ab1.** - **Locally** (git and Python checks only): `scripts/wai-conformance-lists.py selftest` and `check`, `scripts/wai-conformance-lists-selftest.sh`, `scripts/check-changelog-fragment.py` against main, `scripts/changelog-assemble.py --check` and `scripts/changelog-fragments-selftest.sh` all pass. Both rebases, onto 946f3beda and onto one-way's commit, were clean and left every file's change as the conversion first made it. - **On a Linux x86_64 build host:** - in `wai/wai-rs`, `cargo check --locked --no-default-features --tests` under the derived `WAI_FEATURES`, and with each of `impression_aggregate`, `stitched_presentation`, `live_ads`, `receipt_ledger`, `opportunity_report` and `video_ssai` alone, and with one-way's and this branch's features together; - the impression-aggregates, receipt-ledger, live-ads and opportunity-report steps, as CI runs them, through `scripts/wai-conformance-lists.py run --only`: all four pass, so the impressions corpus regenerates byte for byte and its Python verifier passes; - the stitched-presentation step's lines, run by hand after compiling the `wai_stitched_presentation` binary that the workflow compiles first: its library tests and frame tests, `tests/stitched_presentation.rs`, the binary's `vectors verify` and `stitched_presentation_verify.py`. All pass. The step's last line, a `node --test` of joule-moq-web's ad page, was left out: that host has no `node`, and neither branch changes `joule-code/`. - **With the other converted branches.** This branch, stacked as it is, merges without conflict with each of the other branches converted to #632's layout (by `git merge-tree`). Merging all of them in forward, reverse and a mixed order gives one tree. On the build host, that tree passes these runs: `cargo check --tests` under the derived `WAI_FEATURES` and under `WAI_PQ_FEATURES`; `cargo check --tests` of `quickstart,app`; the catalogue's library tests; and the `wai` binary's unit tests. **On the CI hosts.** Results on the CI runners come from this pull request's own CI run. None of the runs above is a CI result. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 3 commits 2026-11-05 04:27:10 -05:00

wai/one-way-delivery, converted to the layout of the fix: no shared append point ... 793ed1f2dc

The change of wai/one-way-delivery (f1258784d..987625394, 28 commits), on the fix branch: its
changelog entries as files of wai/changes/, its wai-conformance.yml edits as step files,
corpus files and test tags, and every other file as the branch has it.

- 25240c4f0 wai: timeliness — when each object of a group is of use, and whether each holder held it in time
- c84992362 wai: timeliness_verify.py — the timeliness corpus's second implementation
- 44036fcdc wai: timeliness in the registry, SPEC §5, the changelog and CI; http_receipts.py checks its claims
- 27ce6754c wai: claim_verify.py lists not-held-by-deadline, and the claim corpus holds a session that switches for it
- 73d8d8eb9 wai: timeliness corpus — each holder's own line in key order, a holder's earliest fallback, and §7.2–§7.3's unreached plan rules
- 64c735f0c wai: the files timeliness changes are clippy-clean — a let chain, and the fetch callback's type allowed
- b72dc36bf wai: rung price — what delivering a rung costs, by bearer and direction, and which option a comparer takes
- 4e905e213 wai: rung_price_verify.py — the rung price corpus's second implementation
- 711fa6126 wai: rung price in the registry, SPEC §5, the changelog and CI
- 8ab70654e wai: rung price corpus — a refusal for every form rule 1 and §6.1 set, and the neighbour order a plan gives
- 1bc465959 wai: rung price ranks energy by checked evidence — a class counts only on the seller's own per-hop records, current and under a confirmed key
- 9e97997d9 wai: rung_price — the evidence text bound at its exact sizes, and a key confirmed for another class confirming nothing
- 8f1168683 wai: rung price corpus — a key confirmed for another class, the uncertainty product, each edge and order of the evidence verdict, and the evidence a plan read
- 7330e26ff wai: rung price — §6.1 links jwp-receipts at its first mention, and §10 says a record's age is its room's word
- 12c099457 wai: cache authority — who served what a node holds, and on whose authority
- f8f5d3e09 wai: cache_authority_verify.py — the cache authority corpus's second implementation
- 354146619 wai: cache authority in the registry, SPEC §5, the changelog and CI; its corpus holds what §12 states
- 55c7f3031 wai: timeliness §6 reads holdings records alone; cache-authority §9 derives the lines that read every kind
- b8fc6f02b wai: cache authority's lines read records as timeliness does, its deadline claim meets the envelopes held, and its corpus fixes each order and instant
- 91c5291cf wai: the files cache authority changes are clippy-clean — a boxed envelope, the base's names named once, slices borrowed
- 8e479daff wai: a held envelope boxes both its forms, so neither outweighs the other
- 3ec8da807 wai: impression aggregates — ad presentations counted over a bearer with no return path
- 0433a35c3 wai: impression_aggregate_verify.py — the impression aggregates corpus's second implementation
- 7d8e150e4 wai: impression aggregates in the registry, SPEC §5, the changelog and CI; its corpus states each receipt whole and a control for every malformed file
- d5e8ace02 wai: impression aggregates' size bounds are checked at their edge, and §4.3's decides no outcome
- 4bc8e13bd wai: impression aggregates' table totals are exact, and a receipt given twice is checked when either occurrence was
- 3c9f20524 wai: key_log's two result enums keep their public form, and say so to clippy
- 987625394 wai: Item::with_authority and Count::instance_received build only with the feature that calls each

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai/ad-consent-supply-chain, converted to the layout of the fix: no shared append point ... d6073e2000

The change of wai/ad-consent-supply-chain (44d5f2264..110c53553, 2 commits), on the fix branch: its
changelog entries as files of wai/changes/, its wai-conformance.yml edits as step files,
corpus files and test tags, and every other file as the branch has it.

- f8fe39cba WAI: an ad decision's consent signal and supply chain, bound into what the decider signs
- 110c53553 WAI: a GPP string links what carries it; a chain per impression; sellers files read exactly

Co-Authored-By: Claude Opus 5.5 <[email protected]>

ad-consent-supply-chain on one-way-delivery: the impressions corpus's records carry no consent signal ... f634e9ab14

PodInput gains `consent` here; the impressions corpus one-way-delivery adds builds its
records with `consent: None`, so each stays a version-1 record with the bytes it had.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit f75a61e9df into main 2026-11-05 10:48:19 -05:00

dcharlot referenced this pull request from a commit 2026-11-05 10:48:19 -05:00

Merge pull request 'wai: an ad decision's consent signal and supply chain, bound into what the decider signs' (#641) from wai/ad-consent-supply-chain into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!641

No description provided.