TMP Router: publisher→router authentication mechanism is not specified

[ohalushchak-exadel]

Context

docs/trusted-match/router-architecture.mdx describes the TMP Router as infrastructure between publishers and buyer agents, exposing POST /tmp/context and POST /tmp/identity. The router:

• Signs outbound requests to providers with Ed25519 (spec'd in detail).
• Verifies inbound requests from providers.

But the inbound publisher → router hop has no auth story:

• The sample deployment YAML in the doc shows listen: :8443 + TLS cert/key, but no auth block.
• The spec text does not say whether a router MUST authenticate its callers, and if so how.
• The "Provider registration security" section covers provider-side keys but not publisher-side callers.

Options a reference implementation has to pick from

1. Leave it to operator ingress. The router accepts anything from 127.0.0.1; operators put mTLS/JWT/HMAC at their load balancer. Doc this explicitly and add X-Forwarded-* handling guidance.
2. Mandate mTLS on the router itself. Publisher client cert verified against a configured CA. Consistent with how providers verify router signatures.
3. Bearer token / shared secret. Simple, common; needs rotation guidance.
4. HMAC-signed publisher requests. Symmetric to the router→provider Ed25519 story; overkill if publishers share the router deployment.

Ask

Please pin down in the spec:

• Whether publisher→router auth is REQUIRED, RECOMMENDED, or "deployment-specific" (and if the last, add explicit ingress-termination guidance).
• If required/recommended, which mechanism(s) MUST/SHOULD be supported by conforming router implementations.
• Whether the router MUST enforce origin binding (e.g. reject a call from publisher X carrying credentials scoped to publisher Y).

A reference implementation (adcp-go) is about to publish a community image and needs to know what to build in vs what to delegate to the ingress layer.

[bokelley]

Triage

Classification: Spec question
Bucket(s): spec/protocol, sponsored-intelligence
Status: ready-for-human
Milestone: Spec Backlog

What the experts said:

• security-reviewer: Architecture doc gap is a real risk — the deployment YAML is copy-paste infrastructure that operators run verbatim; ingress delegation is defensible only with documented constraints on header trust and network binding; origin binding in multi-tenant deployments is the blocking new decision — without it, publisher Y can probe publisher X's targeting under the router's countersignature.
• ad-tech-protocol-expert: "deployment-specific with MUST enforce" matches industry norms (Prebid Server, SSAI routers, OpenRTB endpoints all delegate inbound publisher auth to operators) but is untestable as written; spec line 366 (dynamic-registration auth) already enumerates named profiles at the right level of specificity and is the model to follow; origin binding is a protocol concern in the multi-tenant case because property_rid is a first-class signed field; PR spec(trusted-match): TMP router attestation RFC (experimental) #5770 (attestation RFC, same author, same file) should follow this resolution.

My take: The spec already mandates authentication at specification.mdx line 573 ("The router MUST authenticate incoming requests from the publisher… MUST be enforced") — the gap is that the architecture doc doesn't surface it and the deployment YAML has no auth: block or normative note. Two genuine new decisions remain for the WG: (1) whether to enumerate named conformance profiles (the spec currently says "mTLS, API key, etc." without a minimum bar), and (2) whether multi-tenant routers MUST bind credentials to property_rid scope.

---

Decision A — Named auth profiles

The publisher-to-router section at line 573 should reach the specificity of line 366 (dynamic-registration auth). Three candidate profiles:

Option 1 — Ingress delegation (most common production pattern)

# tmp-router.yaml
listen: "127.0.0.1:8443"   # localhost-only; load balancer enforces auth
# Router MUST NOT trust X-Forwarded-* for auth without verifiable credential
# Router MUST bind to an internal-only interface (not 0.0.0.0) when delegating

Matches how Prebid Server, SSAI routers, and OpenRTB endpoints deploy today; adcp-go community image can ship a reference config showing a conforming Nginx/Envoy setup.

Option 2 — Router-native mTLS

auth:
  mtls:
    ca_cert: /etc/tmp/publisher-ca.crt

Consistent with how providers verify router signatures; requires CA management overhead.

Option 3 — Bearer token + IP allowlist

auth:
  bearer:
    tokens: [{publisher_id: "pub-abc", token_hash: "sha256:..."}]
    ip_allowlist: ["10.0.0.0/8"]   # required with static tokens, per line 366 pattern

Simplest for single-publisher deployments; needs rotation guidance.

All three can be listed as recognized conformance profiles (pick any one = conforming), same pattern as line 366.

---

Decision B — Origin binding (new normative question)

In a single-publisher deployment this is trivially satisfied. In a shared/multi-tenant router:

POST /tmp/context HTTP/2
Authorization: Bearer pub-xyz-token

{"property_rid": "01916f3a-…-pub-abc", "seller_agent_url": "…"}

Without a binding rule, publisher Y's credential can trigger a fan-out under publisher X's property_rid, and the router countersigns it. Proposed addition (mirrors the properties scoping on provider registration):

Where the router serves multiple publishers, the router MUST bind each
credential to one or more property_rid values and MUST reject requests
where the requested property_rid is not within the credential's bound set.
Single-publisher deployments satisfy this requirement trivially.

---

@bokelley, your call on:

1. Should the spec enumerate named profiles (Options 1–3) for testability, or keep "deployment-specific" with no minimum bar?
2. MUST multi-tenant routers enforce property_rid binding per the proposed rule above?

Sequencing note: PR #5770 (TMP router attestation RFC, same author, touches the same file) should wait for this resolution — without publisher→router auth closed, TEE attestation would countersign requests from unauthenticated callers, undermining the trust chain the attestation is meant to prove.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01JcBgCoGNNmJg16NV1j2NR8

---

Generated by Claude Code

[bokelley]

Lineage decision: publisher-to-router authentication needs a complete profile (credentials, signed material, replay rules, failure behavior), not an implicit 3.1 patch. Targeting the profile for 3.2.0.