[Comment] §§ 2.1, 2.2, 4, 5.7, 5.8, 5.10 — Privacy and disclosure guidance across summary, measurement, and agent identity #47

Which section?

Whole document / more than one section

Field(s) involved

visibility, eligible_bidders, required_credentials, catalog_ref, reporting, measurement_source, correlation_id, idempotency_key, assent, payment_terms, invoicing_party

Your comment

Here's the draft — Part 1 is the text you'd paste into the GitHub Comment issue:

Public comment on OpenProposal — AAMP 3.0 draft v3.0-draft-1

Filed by: Rattan Priya Bhasin

I am filing in an individual capacity as a participating member of IAB Tech Lab's AI-Era Attribution Blueprint working group.

Interest declaration: I work on applied AI/ML for privacy-preserving digital advertising. I was on the founding product team of Apple Search Ads, and I regularly participate in the W3C Private Advertising Technology working group. I am reading this draft from the perspective of a practitioner who will build and buy against agent-driven media transactions, with particular attention to privacy and measurement.

I support the draft's direction — especially the no-inheritance rule (a committed record that is self-contained and immutable at agreement is a privacy and auditability win), the idempotency requirement on commitments (§ 5.6.1), and AdCOM continuity from discovery through reporting.

My comments below are offered in that spirit.

1. The Summary Representation needs field-level disclosure guidance (§§ 2.1, 5.3, 5.8). Section 2.1 requires every catalog summary to carry, per line item, audience information — including taxonomy references, provenance, and addressable scale — alongside pricing. That is exactly the information a buying agent needs to compare opportunities, and it is also competitive and potentially privacy-sensitive intelligence about a seller's audience business. Section 5.8 gives each line item a visibility of public, registry_gated, or named — but the draft never says which summary fields are withheld or redacted when visibility is not public. I recommend the draft add a rule or non-normative guidance tying the required summary fields to visibility tiers, so sellers can publish agent-readable catalogs without leaking audience intelligence. This also bears on open question 2: catalog_ref values must resolve during discovery (§ 2.2), which exposes seller catalogs to any discovering agent; guidance on gating catalog resolution to eligible parties would give sellers the control the announcement promises.

2. Measurement choices need privacy-preserving guidance; comparability must not require log-level exposure (§ 5.7 and open question 3). Section 5.7's reporting field offers log_level, aggregate, or no feed, with no guidance on choosing between them. In a privacy-constrained market, log-level feeds carry direct privacy implications. I recommend non-normative guidance on selecting feed types in privacy-constrained contexts, and on how measurement_source qualifiers can declare privacy-preserving methodologies (for example, aggregated or on-device attribution) so a buying agent can transact without demanding user-level data. On open question 3: I agree cross-channel guarantee comparability is unsolved and should be stated as such — but comparability across viewable_rate, completion_rate, and audience-modelled metrics should not require log-level exposure to compute. Privacy-preserving aggregation methods should be first-class inputs to any future normalization, not an afterthought.

3. Define the agent-identity floor; require the correlation ID to be opaque (§§ 4.1, 5.6.1, 5.10). Section 4.1 says assent records use signature scheme "WS1," which the draft never defines. Agents will be negotiating and committing real spend — so the identity and authorization of the agents on both sides is load-bearing, not decorative. I recommend the draft either define the minimum agent-identity requirements for assent or explicitly defer them to the AAMP agent authentication and authorization work, with a pointer. Separately, § 5.10 defines correlation_id as "one identity for this line item's commitment, carried across every system it touches" — a single identifier that travels across every system is a join key. I recommend the draft require correlation_id to be opaque and non-personal — generated randomness with no embedded user, device, or household identifiers — so cross-system reconciliation doesn't quietly create a tracking vector. I support the § 5.6.1 idempotency rule as written.

4. Keep catalog references in 3.0, but gate their resolution (open questions 2 and 6; §§ 2.2, 5.8, 5.10). On open question 2, catalog_ref belongs in 3.0 — without it, large shelves become unwieldy — but the resolution rule should be qualified: a registry_gated or named line item's catalog entries should resolve only for parties that satisfy § 5.8's eligibility. On open question 6, I would leave payment_terms and invoicing_party as inline-or-catalog at the seller's discretion rather than mandating either; the no-inheritance rule (§ 2) is preserved either way.

Thank you to the working group for the draft and for the open process. I am happy to discuss any of the above, including from an implementation perspective as the SDK reference implementations harden.

— Rattan Priya Bhasin

Concrete scenario

No response

You are commenting as

Buyer / advertiser

Before you submit

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