[Change] § 4.1 — Identify the seller by seller_domain; make seller_id OPTIONAL #61

What kind of change?

Add a new field

Which section?

Whole document / more than one section

Current text

§ 4.1:

| `seller_id` | String | immutable | IAB Tech Lab registry reference |
| `seller_name` | String | immutable | Canonical legal seller entity name, from the registry |

Proposed text

Our shared types PR adds Party to § 2.2. Its REQUIRED domain is the identifier. Its OPTIONAL registry_id attests that domain. Absent or unresolvable, it never makes a document malformed. A consumer ignores an entry whose verified domain isn't domain. Our parties PR types seller and buyer as Party, and closes this issue. § 4.1, replacing both rows:

| `seller` | Party | REQUIRED | immutable | The selling entity. `seller.domain` is the seller's identifier for all purposes, including `assent[]`. `legal_name` is REQUIRED here |

A seller MUST NOT name a domain it does not control.

Where a third party hosts a seller's agent or published files, `seller.domain` is the
selling entity's own registrable domain, never the host's.

Why

A proposal names its seller only by seller_id, a registry reference with no link, format, or resolution procedure. We ask that the seller's registrable domain identify it, and that the registry reference attest that domain.

Without a domain, a buyer can't check that a manifest (#29) or a resold line item (#28) names the seller that served or sourced it. A registry outage has no defined outcome.

A signature proves an https origin, under the Web Bot Auth profile in our signing PR. An assent[] entry is attributed to a party when that origin's host is the party's domain or a subdomain. #47 (item 3) and #45 need a named seller to bind assent to.

Knock-on effects

• buyer, agreement.parties[] (#27), and the billing parties are Party values. eligible_bidders[] (§ 5.8) splits into eligible_buyers[] and eligible_seats[].
• [Change] § 2.3 — Static manifest at a well-known URL for standard proposals #29 and #76 publish the manifest at https://<seller.domain>/.well-known/openproposal.json. In the parties PR, a buyer discards an entry whose seller.domain isn't the requested URL's domain, before any redirect.
• proposal_id is unique within seller.domain, so a reference outside its proposal, such as [Change] § 2.1, § 5.10 — Cross-publisher composition: searchable summary metadata and source_ref #28's source_ref, keeps the domain beside it (#31).
• The rules issue asks about two related checks: a fetched Full Representation's seller.domain against the manifest, and legal_name against the registry.

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.

Details and examples: Seller identity by domain: full rationale and examples

Revised 2026-11-03: Rewritten to match our PRs: the title's seller_domain became seller.domain, and its seller_id the OPTIONAL registry_id.

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