[Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory

What kind of change?

Change a field's type or shape

Which section?

5.2 — Inventory composition

Field(s) involved

properties.available[]

Current text

properties.available[] items are { id, name, domains, supported_formats }.

Proposed text

Add an app identity to the property object, and require at least one of domains or apps:

{ id, name,
  domains?: [...],
  apps?: [{ store: ios | android | roku | fire_tv | samsung_tv | ..., store_id, bundle_id, developer_domain? }],
  supported_formats }

Note in the field description that authorisation for app inventory resolves through app-ads.txt (published on the developer domain from the store listing), not through the property's domains.

Why

environments already enumerates app_mobile and ctv, but the only identity a property can carry is a web domain. In-app and CTV-app inventory is identified by store id / bundle id — that is what AdCOM, app-ads.txt, sellers.json and every DSP keying on the bid request use. Without it a buying agent cannot match an app line item to its brand-safety lists, run its app-ads.txt check, or join its own historical performance data, and the downstream OpenRTB app.bundle / Deals API line cannot be pre-filled from the proposal.

Knock-on effects

§2.1 summary representation lists "property names"; it should list the app identifier too.
Partly answers open question 7 (environments[] validation): app_mobile and ctv need app identity to be validatable at all.

Would this break an implementation already built to this draft?

No — additive; domains keeps working for web properties.

Alternatives you considered and rejected

Putting the bundle id in content_detail or external_references[]: both are free-form, so buyers could not key on them reliably.
A separate app_properties field: splits one concept in two and forces the no-inheritance rule to be restated for each.

Concrete scenario

A CTV line item lists property { id: "weather-app", domains: ["exampleweather.com"] }. The buyer's agent runs its app-ads.txt check against the Roku channel id and has nothing to key on; the same line item, once agreed, cannot be handed to the DSP as an app.bundle deal.

You are commenting as

SSP — an in-app supply-side exchange (mobile + CTV) selling preferred-deal / private-auction / open-market inventory to buyer agents over AAMP and AdCP; we run the seller side of both today.

Before you submit

I have read the draft section I am commenting on.
This contains no confidential or commercially sensitive information.

Thank you for raising this.

We agree in principle. § 5.2 properties currently carry only web domains, so app_mobile and ctv inventory cannot be identified, verified against app-ads.txt, or carried into the downstream OpenRTB request.

Rather than introduce new names, we propose aligning apps[] with the OpenRTB 2.6 app object:

apps: [{
  platform,   # ios | android | roku | fire_tv | samsung_tv | ...
  bundle,     # OpenRTB 2.6 app.bundle: the app's store ID
  storeurl,   # OpenRTB 2.6 app.storeurl
  domain      # OpenRTB 2.6 app.domain: the developer domain used for app-ads.txt
}]

As OpenRTB 2.6 defines bundle as the store ID, it covers both store_id and bundle_id from your proposal. platform has no OpenRTB equivalent and would be defined by OpenProposal.

Draft PR #17 applies this to the § 5.2 property object and the CTV example. Appendix A is unaffected, as apps is a key within properties rather than a new field. The PR will remain in draft until the working group confirms the disposition of this issue.

This issue also bears on OQ-7 (#8): app_mobile and ctv cannot be validated against real inventory without an app identity.

Related: #25 proposes buyer-supplied block lists, including an app_bundle exclusion type. If app identity is added to properties as proposed here, the two should use the same app identifier.

Make the app developer domain RECOMMENDED

Agree with the direction in #17, and aligning on the OpenRTB 2.6 app object is the right call. For CTV there is one case it does not cover yet: the party selling is often not the app owner.

A FAST channel or content library is commonly distributed through several CTV apps at once, and under an inventory share the channel owner sells part of the ad time inside apps it does not own. In that case authorization runs through two files, not one. The app owner lists the channel owner's domain as an inventorypartnerdomain in its app-ads.txt (ads.txt 1.1), and the channel owner's own ads.txt lists the sellers authorized for that share. OpenRTB 2.6 carries the same thing as app.inventorypartnerdomain, and carries the channel and its parent network as content.channel and content.network, each with id, name and domain.

With #17 as drafted, a channel owner can list every app its channel runs in, which helps. But a buying agent following the rule that authorization is checked through app-ads.txt on the developer domain will look only in the app owner's file, not find the channel owner's seller there, and conclude the line is unauthorized. Nothing on the property says whose channel it is either, so after agreement the deal carries the apps but not the channel the buyer actually chose.

Two suggested additions, both optional and both keyed to OpenRTB 2.6:

properties:
  available:
    - id: "example-channel"
      channel: { id: "ch-123", name: "Example Channel", domain: "channel-owner.example" }    # as content.channel
      network: { id: "nw-9", name: "Example Network", domain: "network-owner.example" }      # as content.network
      apps:
        - { platform: roku, bundle: "000000", domain: "app-owner-a.example",
            inventorypartnerdomain: "channel-owner.example" }                                 # as app.inventorypartnerdomain
        - { platform: samsung_tv, bundle: "111111", domain: "app-owner-b.example",
            inventorypartnerdomain: "channel-owner.example" }
  included: ["example-channel"]

And one sentence for the authorization note: "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."

This would also partly answer the point in #17 that the object has no field in which a seller claims app-ads.txt authorization. For shared inventory, inventorypartnerdomain is that claim, and a buyer can check it.

Commenting in a personal capacity. Product leader in CTV, identity and data; I have led teams that built DSP bidding, household identity graphs, and CTV ad insertion and monetization platforms. I maintain OpenCTV, an open-source, non-commercial project on CTV ad delivery diagnostics.

Correct the developer domain and define platform as the issuing store

Navigation Menu

Repository navigation

[Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory #15

What kind of change?

Which section?

Field(s) involved

Current text

Proposed text

Why

Knock-on effects

Would this break an implementation already built to this draft?

Alternatives you considered and rejected

Concrete scenario

You are commenting as

Before you submit

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Change] § 5.2 — App identity on properties (store id / bundle id) for app_mobile and ctv inventory #15

Description

What kind of change?

Which section?

Field(s) involved

Current text

Proposed text

Why

Knock-on effects

Would this break an implementation already built to this draft?

Alternatives you considered and rejected

Concrete scenario

You are commenting as

Before you submit

Activity

Sirajmx commented on Oct 6, 2026

Sirajmx commented on Oct 8, 2026

unreconciled commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions