[Change] § 5.2 — State the seller's relationship to each property, checkable against ads.txt #88

What kind of change?

Change a field's type or shape

Which section?

5.2 — Inventory composition

Current text

| `properties` | Object | selectable | `available[]` of `{ id, name, domains, supported_formats }`, `included[]`, `pricing`, `max_select` |

Proposed text

§ 5.2, in the `properties` row as amended by PR #17, add `seller_relationship`,
`inventorypartnerdomain`, and `seller_accounts` to each `available[]` entry.
The row keeps "Each property MUST carry `domains`, `apps` or both".

Add after the table:

**Seller relationship.** Each property states by what right `seller_domain` sells it.

| Key | Required | Meaning |
| :--- | :--- | :--- |
| `seller_relationship` | REQUIRED | `owner` \| `manager` \| `inventory_partner` \| `reseller` |
| `inventorypartnerdomain` | OPTIONAL | As OpenRTB 2.6 `site.inventorypartnerdomain` and `app.inventorypartnerdomain` |
| `seller_accounts[]` | REQUIRED for `reseller`, or when `transaction_mechanism.available[]` holds any value other than `DIRECT_IO` | `{ asi, sid }`, as ads.txt field 1 (Domain name of the advertising system) and field 2 (Publisher's Account ID) |

The governing file is the ads.txt of each `domains[]` entry, or the app-ads.txt
of the developer domain in the app's store listing (found by `storeurl`, or by
`platform` and `bundle`), not `apps[].domain`. For `seller_accounts[]`, it is
the ads.txt of `inventorypartnerdomain` when present, or of `seller_domain`
when `seller_relationship` is `inventory_partner`.

| `seller_relationship` | The governing file declares |
| :--- | :--- |
| `owner` | `OWNERDOMAIN` equal to `seller_domain`. With no `OWNERDOMAIN`: the domain serving the file equal to `seller_domain`, or a `DIRECT` record for a `seller_accounts[]` entry that sellers.json types `PUBLISHER` or `BOTH` |
| `manager` | `MANAGERDOMAIN` equal to `seller_domain`, global or for every country the line item's `geo` allows |
| `inventory_partner` | `INVENTORYPARTNERDOMAIN` equal to `seller_domain` |
| `reseller` | A `RESELLER` record for a `seller_accounts[]` entry |

Each `seller_accounts[]` entry MUST be a record in the governing file.
A seller MUST NOT state a relationship its governing file, where one exists, does not support.
A consumer that checks MUST use this table, and confirms that sellers.json at
`asi` lists `sid` as a `seller_id`, with `domain` equal to `seller_domain` where
the entry carries `domain`. With no governing file, or a confidential entry,
the claim is unverifiable, not failed. Whether to check, and what follows, is buyer policy.

PR #17, `apps[].domain`: "against which `app-ads.txt` is checked" becomes
"informative; the governing developer domain comes from the store listing".

§ 2.1, Summary Representation: add each property's `seller_relationship`.

Why

§ 5.2 lets a seller list any domain or app without saying by what right it sells it. We ask each property to state the seller's relationship and the accounts a buyer checks against the publisher's own file.

On PR #17 the maintainer noted that "the object has no field in which a seller claims app-ads.txt authorisation". This is that field, for web and app. ads.txt 1.1 names owners, managers, and inventory partners by domain (ads.txt 1.1 variables) and resellers by account (ads.txt 1.1 data record), OpenDirect included. sellers.json maps each account to a domain (sellers.json Seller object). Keyed on seller_domain (#61), each check compares one key. The stated label says which file and key to read, and lets a buyer screen the § 2.1 Summary Representation without a fetch.

ads.txt 1.1 only recommends OWNERDOMAIN, so many files lack it. An owner selling under another domain then shows ownership the way the files already do: a DIRECT record, which means "the Publisher (content owner) directly controls the account" (ads.txt 1.1 field 3), and a PUBLISHER or BOTH entry (sellers.json seller_type).

The seller writes apps[].domain, so it can't govern: app-ads.txt takes the developer domain from the store listing.

A DIRECT_IO line item never meets a bid-time ads.txt check, so this is the only authorization check its buyer can run before committing.

Definitions: OpenRTB 2.6 Object: Site and Object: App inventorypartnerdomain, OpenRTB 2.6 Object: SupplyChainNode asi and sid.

Details: Seller relationship: full rationale and examples.

Knock-on effects

• Depends on #61 for seller_domain.
• #15 and PR § 5.2 — App identity on properties (#15) #17: the row assumes PR § 5.2 — App identity on properties (#15) #17's apps[], and its authorization note becomes the app row. @unreconciled's inventorypartnerdomain moves to the property, so sites get it, as in OpenRTB 2.6.
• #28: source_ref says where a line item came from; seller_relationship, by what right.
• Known gap: a non-exclusive sales rep has no value. MANAGERDOMAIN names only "the primary or exclusive programmatic seller" (ads.txt 1.1 variables), and reseller needs a RESELLER record. We leave that case to the working group.
• No marker or Appendix change; the check reads public files, so no round trip. § 6.2 and § 6.3 gain the keys.

Open questions for the working group

1. Should a non-exclusive sales rep that sells by IO get its own seller_relationship value, checked against a key the publisher's file would need to add, or stay out of scope until ads.txt names that role?
2. Should seller_relationship be REQUIRED, which breaks draft-1 producers as proposed, or RECOMMENDED, with an absent value meaning the buyer can't check the claim?
3. Should inventorypartnerdomain sit on the property, as proposed, so sites get it as in OpenRTB 2.6 site.inventorypartnerdomain, or on each apps[] entry, as @unreconciled proposed on app identity on properties (#15), which allows a different partner per app?
4. Should the apps[].domain change, which takes the governing developer domain from the store listing, go into the app identity PR (#17) before it merges, or follow as a separate change?
5. Should the working group confirm with the Supply Chain Validation group two uses that go beyond ads.txt 1.1's bid-time logic: the owner fallback for files without OWNERDOMAIN, which the logic in the ads.txt 1.1 Implementation Guide would classify as a reseller, and the pre-commit use of INVENTORYPARTNERDOMAIN, which ads.txt 1.1 § 5.7 INVENTORYPARTNERDOMAIN directives applies where the bid request carries it?

Would this break an implementation already built to this draft?

Yes — breaking

You are commenting as

Other — IAB Tech Lab member (Postindustria).

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.

Analyzed and generated with the help of Claude, fully reviewed by me.