[spec] Click-context contributing sources must not be limited to the presentation turn; allow consent-gated session scope

[pedroamaralsantos]

Specification section

Content Telemetry §7.4.4 (click-context resolution), item 3 (contributing_sources).

---

What you observed

PR #38 replaced the v0.1 click manifest (consent-gated content_grounded / content_cited / content_presented for the resolved session) with a click context:

1. The bound engagement
2. Lineage of the clicked content only (all turns, by content identity)
3. Contributing sources for other content — gated per owner opt-in, but scoped to the engaged presentation’s turn (plus session-scoped groundings)
4. Optional count-based session_summary

Item 2 is right for “what happened to the URL they clicked?” Item 3 is the only place other publishers appear, and it is one turn, not the session.

v0.1 could return every opted-in source in the session. Now a publisher cited only in an earlier turn is dropped when the user clicks an advertiser presented in a later turn.

Turn 2: publishera.com grounded + cited
Turn 5: advertiser.com presented; user clicks it

v0.1 click manifest (opt-in):  publisher A is visible
§7.4.4 item 3 today:           publisher A often absent (wrong turn)

session_summary (counts, no peer identities) does not restore that chain. Lineage of advertiser.com does not include publishera.com.

---

Why it matters

Affiliate / commerce attribution is: this click on advertiser.com was informed by publisher A (and B, C, …). Those sources are often not the clicked URL, and they are often not all in the same turn as the presentation the user clicked.

Limiting contributing sources to the presentation turn:

• Drops earlier-turn reviews/guides that shaped the later click
• Makes resolve narrower than the v0.1 consent-gated click manifest: opted-in sources from other turns in the same session no longer appear
• Leaves a party that only sees the click URL (e.g. a network or advertiser that captured ctx_token on the redirect, and does not receive publishers’ §7.3 event streams) unable to see opted-in publishers from the rest of the dialogue — resolve is their only lookup

We are not asking for an ungated dump of every owner. Consent / opt-in should stay. We are asking that, when an owner has opted in, their contributing events not be discarded solely because they sit in another turn.

Why today’s nearby mechanisms are not enough

§7.4.4 already keeps session-scoped content_grounded events in the click-turn contributing-source set, and §7.3 still gives each owner their own filtered event stream. Neither replaces a consent-gated contributing-source list on resolve that can include earlier turns:

• Session-scoped grounding ≠ citation / presentation. A content_grounded with scope: session from turn 2 MAY still appear on a turn-5 resolve. A turn-2 cite or present does not. Attribution often needs “they were cited / shown,” not only “they were ingested once at session start.”
• Not all groundings are session-scoped. Turn-scoped grounding in turn 2 is out of scope for a turn-5 click under today’s item 3.
• §7.3 is a different path. Owner-filtered views (and §7.4.5 click delivery) help a destination or a network that already receives those streams and can join on session_id. A party that only holds ctx_token on the advertiser hop still has to use resolve. That token lookup needs to return the opted-in chain; it is not the same as “also subscribe to each publisher’s §7.3 feed.”

---

Proposed improvement

Keep engagement + clicked-content lineage as they are. Change item 3 so contributing sources can cover the session (consent-gated), not only the presentation turn.

Simple option — one opted-in window. When a contributing owner has opted in to contributing-source disclosure, resolve includes that owner’s grounded / cited / presented events for the session (or at least all turns that existed at click time). Same opt-in gate as today; only the time scope changes. No extra levels.

More flexible option — explicit consent levels. If parties need different cuts, make the window a recorded choice rather than a silent one-turn default:

Level	Contributing-source window
session	Opted-in sources across the session
through_click_turn	Opted-in sources from turn 1 through the engaged presentation’s turn (+ session-scoped groundings)
click_turn	Today’s rule — that turn only (+ session-scoped groundings)
none	No contributing-source events

Who picks the level is the same kind of choice as today’s contributing-source opt-in: recorded with the consumer (agent, owner, or both — the spec does not have to name the API). If an owner (or the agent on their behalf) granted session or through_click_turn, the consumer MUST return that window on resolve.

[jchomat]

Supporting this from a press publisher perspective.

The turn-scoped limit breaks the most common editorial attribution scenario: a user reads a review or guide article (turn 2), asks follow-up questions (turns 3–4), then clicks a product or advertiser link in turn 5. The editorial content that shaped the click is in an earlier turn and drops out of the contributing-source list entirely.

This is not an edge case for press publishers — it is the normal shape of an informed click. Session-scope with consent opt-in (the simple option proposed here) is the right fix. The through_click_turn level would also work for our use case if the working group prefers an explicit consent ladder.

[jalexspringer]

Recording the disposition this thread was owed. v1.0 ships the contributing-source component scoped to the engaged presentation's turn, session-scoped groundings included; the clicked content's own lineage crosses turns by content identity (section 7.4.4). The narrowing from the v0.1 click manifest is deliberate: a resolution request is authenticated by nothing more than possession of a URL-carried token, and whole-session cross-owner detail over that channel is the exposure 7.4.4 exists to prevent — cross-turn, cross-owner reporting stays on the owner-filtered path (7.3), which authenticates the recipient. Consent-gated session scope needs the requester-authentication work that 7.4.6 defers to the evidence profile; once resolution can authenticate the requester, this is worth reopening. Labelling post-v1 rather than closing.

[pedroamaralsantos]

@jalexspringer Thanks for having a look into this issue. Isn't it a privacy concern to be able to get this reduced data by using only the ctx_token? We need to be aware that users will share internet links containing these tokens. Furthermore, URL referrer headers, third-party scripts on advertiser websites, and Chrome extensions can collect these tokens. I can see this data being used by third parties to build products on top of it and sell it.

My proposal assumed resolve would sit behind an authenticated endpoint, and I agree 100% that it cannot be accepted without requester authentication. My first impression is that we need to address this lack of privacy. Don't you also see a potential problem here? What are your thoughts?

I haven't put much thought into a full design yet, I'd first like feedback on the general privacy concern, but I could open a separate issue to address it.

One direction that seems compatible with the existing manifest model: participants publish asymmetric keys in /.well-known/content-telemetry.json (§8.4 keys[] — today optional for any role: content_owner, agent, or platform, and currently defined for signing telemetry events they emit). A resolve caller could present a short-lived JWT signed with their private key; the consumer would fetch the manifest and verify it with the published publicKey. That would avoid central registration with the consumer for identity, while the consumer still applies policy (consent, scope).

For authorization, I could imagine extending manifests so a destination lists delegated resolver manifest URLs — e.g. advertiser.com lists an affiliate network's manifest URL, and the consumer can accept a signed request from that network when resolving clicks to that destination.

In the request, the affiliate network would provide its manifest URL, the ctx_token, and the signed JWT. The consumer would check whether that manifest URL is authorized for the clicked destination, fetch the network's public key, and validate the JWT (including expiry and binding to the token).

Happy to open a follow-up issue if useful — wanted your read on the privacy concern first.