[Sirajmx]

Draft. Do not merge until the working group confirms the disposition of #15.

What this changes

§ 5.2 properties can now identify apps as well as web domains. Each property in properties.available[] may carry apps[] with platform, bundle, storeurl and domain, keyed as the OpenRTB 2.6 app object where one exists. Each property MUST carry domains, apps or both. A note states that seller authorisation for an app is checked through app-ads.txt on its developer domain. The CTV example now carries an app identity.

Related issue

Refs #15

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated
• Appendix A (field index) matches the body — no new top-level field; apps sits inside properties
• Appendix B (fields by marker, and the counts) matches the body — unchanged
• Any affected example in examples/ is updated and still parses
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2)
• No confidential or commercially sensitive content

Knock-on effects

• domains is no longer always present. A consumer that assumed it was must handle a property carrying only apps.
• OpenRTB: bundle, storeurl and domain map directly to the 2.6 app object. platform has no OpenRTB equivalent.
• Related to OQ-7 (OQ-7 — environments[] needs validation against real inventory #8): app_mobile and ctv can't be validated against real inventory without an app identity.

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

[fgranata]

This shape works for us — bundle + platform is exactly how we key app inventory, and aligning on the OpenRTB 2.6 app object is better than the new names we proposed.

One suggestion on domain: the text says seller authorisation is checked through app-ads.txt on the developer domain, but domain is OPTIONAL, so a buyer has nothing to run that check against when it is absent. Consider "SHOULD be present; REQUIRED when the seller claims app-ads.txt authorisation for the app" (or simply SHOULD).

[Sirajmx]

Thank you. Agreed: without domain, a buyer has nothing to run the app-ads.txt check against.

We have updated the PR to make domain RECOMMENDED (SHOULD, in RFC 2119 terms) rather than OPTIONAL. We kept it at RECOMMENDED rather than a conditional REQUIRED, as the object has no field in which a seller claims app-ads.txt authorisation, so the condition could not be checked. A buyer can still fall back to the developer domain in the store listing (storeurl) when domain is absent.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Sirajmx, four points on App identity:

• domain: OpenRTB 2.6 app.domain is "Domain of the app", not the developer domain, and app-ads.txt takes the developer domain from the store listing. Seller relationship on properties (#88) proposes text for this.
• platform mixes operating systems (ios, android) and devices (fire_tv, samsung_tv), but bundle is unique only within a store: an Amazon Appstore app fits both android and fire_tv. Defining platform as the store that issued bundle, as in the OTT/CTV Store Assigned App Identification Guidelines that app.bundle cites, fixes the values for block lists (#71). That ID is AdCOM 1.0 App.storeid, not App.bundle.
• Issue [Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory #15 asked the Summary Representation (§ 2.1) to list the app identifier.
• @unreconciled's inventory-share case is unanswered. Under the authorisation sentence, a buyer reads only the app owner's file and rejects the channel owner's share. [Change] § 5.2 — State the seller's relationship to each property, checkable against ads.txt #88 adds inventorypartnerdomain for it.

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

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Sirajmx, thanks for developer_domain and the platform definition. Three points remain at 63d86c0:

• developer_domain. The seller writes it, so a seller can point it at a file that lists the seller. app-ads.txt takes the developer domain from the store listing. We suggest keeping it RECOMMENDED and ending the row "informative; the governing developer domain comes from the store listing". Open question 4 on #88 asks about this under the old name.
• Inventory share. @unreconciled's case has no answer in this PR. Under the authorization sentence, a buyer reads only the app owner's file and rejects the channel owner's share. Their sentence fixes it: "Where inventorypartnerdomain is present, authorization is checked through the app owner's app-ads.txt entry for that domain and then through the ads.txt on the inventory partner's domain." #88 proposes the field. We suggest it sit on the property as inventory_partner_domain, with the selling accounts checked against that domain's ads.txt.
• Names. We suggest keying an app as AppId { store, bundle }, the pair a block list holds too. An App table holds the AppId keys, store_url, and developer_domain. platform becomes store, because the key holds a store, not a device. Its terms: ios becomes apple_app_store, android becomes google_play, roku becomes roku_channel_store, fire_tv becomes amazon_appstore, and samsung_tv becomes samsung_apps_tv. storeurl becomes store_url.

Our coming property option PR merges this PR at its head and applies these three points. Once it's open, could you review them there, or adopt the changes here?

Revised 2026-11-04: Added the names point, the field name inventory_partner_domain, and the property option PR that applies all three points. Dropped the bundle point, which our first comment makes.

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