[spec] A ctx_token alone does not identify which telemetry consumer can resolve it

[pedroamaralsantos]

Specification section

7.1 (ctx_token issuance and resolution), 7.3 (Routing and aggregation)

What you observed

Section 7.1 says the agent issues an opaque ctx_token on click-out, and a telemetry consumer resolves that token to the session’s click manifest. Section 7.3 allows that consumer to be platform-hosted, marketplace-hosted, or a third party.

What a holder of a ctx_token cannot do from the token alone: know which party issued it, or which telemetry consumer can resolve it. The token is opaque (ct_…-style examples in fixtures) with no issuer, consumer, or routing hint. There is no specified format that would let a destination, affiliate network, or other intermediary pick the correct resolve endpoint.

Why it matters

Resolve only works if the requester can address the consumer that holds the session map. Without a reliable way to identify that party from the ctx_token, any entity that receives a click token is stuck:

Destination / network holds:  ctx_token=T
Spec says:                    "ask a telemetry consumer to resolve T → click manifest"

Missing:                      which consumer? how do you know from T?

Consequences:

• When a destination or affiliate network receives a ctx_token, it has no way to determine which telemetry consumer is able to resolve it. As a result, the only option is to query every known telemetry consumer, which is inefficient, increases unnecessary traffic and latency for token resolution, and adds operational complexity. additionally, the specification doesn't explain, or solves the issue around discovering new telemetry consumers. If all known consumers do not have the click manifest, it means it was generated by an unknown telemetry consumer.

Proposed direction (optional)

The specification should define a reliable way to identify, from a ctx_token, which telemetry consumer can resolve it (or which issuer/operator to start discovery from).

One possible option (among others):

• Structured / prefixed token — ctx_token follows a pattern that embeds a non-secret issuer or consumer identifier (e.g. ct_<consumer_or_issuer_id>_<opaque>), so any holder can route resolve to the right party.

OpenAttribution would maintain a directory mapping each consumer ID to entity information (name, URL, etc.) for the party responsible for operating that consumer.

Consequence: a holder of a ctx_token can look up the consumer in the directory hosted by OpenAttribution, then query that consumer directly with the token to obtain the click manifest.

Your perspective

None

[jalexspringer]

Agreed: the recipient needs to know where the token can be resolved.

Keep ctx_token opaque. Carry an issuer or manifest locator alongside it, with the manifest declaring the resolution endpoint. That avoids both token-embedded routing and a mandatory central registry.

I’ll treat this, #23 and #28 as one v1 click-context change.

[pedroamaralsantos]

Thanks — this comment focuses on #30 (discoverability) and #23 (transport). We are happy to group #23, #28, and #30 in a single spec change; however, #28 still needs further discussion. This comment doesn't focus on the issue 28.

What we agree on

• Recipients must know where to resolve a token; ctx_token alone is not enough.
• Keep the token opaque (no information about issuer)— carry an issuer or manifest locator alongside it instead of embedding routing in the token. We are happy with this approach for discoverability ([spec] A ctx_token alone does not identify which telemetry consumer can resolve it #30).
• The participant manifest (§8) declares the resolution endpoint; no mandatory central registry.

Transport suggestions (#23)

Considering your suggestion, our proposal is that the manifest locator should travel on the click-out URL with the same redirect-chain expectations as ctx_token. Two shapes seem workable:

• Option A: separate params — ctx_token + ctx_manifest (final query string parameter name TBD); both MUST be preserved through the chain (§7.2 parity and like suggested for ctx_token parameter in issue [spec] ctx_token transport and redirect-chain propagation for click-out #23).
• Option B: single bundled param — ctx_data=<url-encoded manifest URL?ctx_token=…>(final query string parameter name TBD); one param to preserve through the chain.

We also suggested a documented value prefix for the token (e.g. ct_…) so parties can locate it by pattern, not only by query parameter name. In that regard, Option B looks stronger: the encoded URL has high potential to be found by pattern even when the parameter name is unknown or changed for some reason(eg:collision). It also leaves only one parameter to preserve across redirects, which simplifies chain handling.

Do you have other ideas how to handle the manifest locator? Is Option B also your preference?

Thank you!

[jalexspringer]

Disposition: accepted as agreed above. ctx_token stays opaque; an issuer or manifest locator travels alongside it; the participant manifest (§8) declares the resolution endpoint. No token-embedded routing, no mandatory central registry. This lands in the single click-context change with #23 and #28 — and #28's remaining question is answered there. Open until that change merges.

[jalexspringer]

The click-context change is up as PR #38: one change covering token pattern and per-presentation binding, the reserved ctx_token/ctx_iss query parameters with redirect propagation, manifest-declared resolution (telemetry.ctx_resolution), and the resolution response specified as the engagement plus the clicked content's lineage by content identity across turns, with an optional count-based session summary. Review welcome there before the 21 August freeze.

[jalexspringer]

Landed in v1.0 (sections 7.4.2, 7.4.3, and telemetry.ctx_resolution in 8.5). On the Option A/B question left open above: the two-parameter shape — opaque ctx_token plus ctx_iss locator — was chosen over a bundled value because the token stays opaque and the routing stays independently inspectable and strippable; a combined value would couple the two and invite destination-side parsing. Closing.