[Question] § 5.3 — Machine-readable attestations for buyer_supplied data provenance and diligence #116

What kind of change?

Add a new field

Which section?

5.3 — Audience reach

Current text

| `buyer_supplied` | Object | supplied | `{ segments_allowed, suppression_allowed, match_rate_expected, segments[], suppression_list }`. `match_rate_expected` is the seller's stated expectation; `segments[]` and `suppression_list` are buyer-populated |

Proposed text

"buyer_supplied": {
  "segments_allowed": true,
  "suppression_allowed": true,
  "match_rate_expected": 0.65,
  "segments": [],
  "suppression_list": [],
  "diligence_ref": "string" // or `attestation_ref`
}

Why

Issue #108 rightly addresses the mechanics of the data-sharing handoff (how data moves via S3, Snowflake, clean rooms, etc.). However, the current OpenProposal object model describes the transport without capturing the authorization or attestation that must logically precede it.

In an agentic workflow, a seller's automated compliance agents cannot safely execute a match count or a data ingestion without verifying that the buyer agent is authorized to provide those segments. While AAMP 2.3 integrated the IAB Diligence Platform into the execution layer, OpenProposal (§ 5.3) lacks a mechanism for the buyer to assert this diligence at the proposal stage.

This proposal is not asking OpenProposal to define privacy semantics, consent frameworks (TCF/GPP), or data lineage standards. It is simply asking the protocol to provide a standardized "trust boundary" pointer (diligence_ref).

If the spec lacks an attestation model, the RFP workflow becomes a compliance bottleneck. A buyer agent might optimize for reach/CPM and commit to an RFP, only for the seller to reject the subsequent data handoff because the buyer cannot attest to the provenance of the audience. Providing a generic attestation reference ensures:
Lineage and Trust: The agreed proposal object becomes a self-contained record that the buyer asserted the right to transact.

Protocol Extensibility: Today this pointer references audience diligence; tomorrow it could reference healthcare certification (HCP scenarios), geographic data residency requirements, or political advertising approvals.

Scope Preservation: It preserves flexibility and interoperability without forcing the OpenProposal WG to become a privacy standard-setting body.

diligence_ref (optional, string): A reference to external diligence, consent, or audience provenance documentation maintained outside OpenProposal. This serves as a machine-readable attestation by the buyer agent that prerequisite conditions for the requested data handoff (as configured via activation_route or Issue #108 mechanisms) have been satisfied.

Knock-on effects

• Downstream Standards (OpenDirect / Deals API): Binding diligence_ref into the resulting Deal object — so that the execution layer inherits the trust boundary established at the proposal stage — is the desired end state, but it is out of scope for this change request. It will require a corresponding change request to OpenDirect (and, where relevant, the Deals API), covering the contract generation phase and the Deal object's field surface. This issue flags that knock-on effect rather than asserting it. Until such a change lands, OpenProposal's guarantee is limited to preserving the attestation in the agreed proposal record, where it remains available for out-of-band diligence and audit.

• OpenRTB 2.6: At the bid-request level, OpenRTB does not need to carry the diligence_ref directly. The deal.id in the OpenRTB request implicitly resolves back to the OpenProposal object where the attestation lives, maintaining separation between commercial discovery (OpenProposal) and transactional execution (OpenRTB).

• Examples in § 6: The HCP (healthcare) and clean-room examples from Issue [Comment] § 5.3 — Buyer-supplied audience match: reachable count, avails, and data-sharing handoff #108 would simply include "diligence_ref": "uri:iab-diligence:12345" to demonstrate how a buyer agent signals compliance before the seller agent executes the match.

• "Resolves without a round trip" guarantee (§ 3): Because this is an optional string reference (URI/ID) rather than a nested object requiring recursive validation, it preserves the lightweight parsing guarantees of the spec. The actual resolution of the diligence assertion happens asynchronously out-of-band, mirroring how catalog_ref resolutions are handled.

• No-inheritance rule: The diligence_ref remains strictly scoped to the buyer_supplied object. It asserts authority over the buyer's inputs (segments/suppressions) and does not inappropriately inherit into the seller's catalog, pricing, or environments.

Would this break an implementation already built to this draft?

No — additive or editorial

Alternatives you considered and rejected

1. Embedding the full privacy/consent payload (e.g., full TCF string, SafeGuard object) directly in the proposal:
Rejected: This bloats the proposal object massively and violates the separation of concerns. A proposal should remain a lightweight commercial menu. Embedding nested consent graphs would break the lightweight parsing guarantees of the spec.

2. Handling diligence strictly out-of-band with no machine-readable footprint in the proposal:
Rejected: While the actual data lives out-of-band, the assertion of authority must be machine-readable for agentic workflows. If buyer and seller agents negotiate at machine speed, a lack of a machine-readable signal forces agents to blindly attempt data matches, resulting in automated compliance failures, wasted compute, and broken execution SLAs. The protocol needs a machine-readable trust boundary.

3. Defining normative privacy semantics within OpenProposal (e.g., adding hipaa_compliant or gdpr_tcf booleans/fields):
Rejected: Scope creep. OpenProposal is a commercial protocol, not a privacy standard. Hardcoding regulatory frameworks (GDPR, CCPA, PIPL) into the object model would make the spec brittle to future legal changes. A generic pointer (diligence_ref) future-proofs the protocol against regulatory evolution.

You are commenting as

Individual, no organisational position

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.