Canonicalization now strips a trailing FQDN-root dot; the spec defines no rule and ships no vector

[KonstantinMirin]

Summary

@target-uri / @authority canonicalization now strips a trailing FQDN-root dot from the host. This is a wire-visible change and the AdCP spec does not define the behaviour either way, so it is filed here to make it visible and to ask that upstream decide it.

Before: https://example.com./p → authority example.com.
After: https://example.com./p → authority example.com

Landed in #985 (feat(signing): reject malformed authorities, convert IDN hosts to A-labels).

Why the change was forced

#985 makes the signing path call _idna_canonicalize.canonicalize_host for non-ASCII hosts, which is the package's designated host normalizer and already has six consumers. That helper strips one trailing root dot as part of its UTS-46 preparation. The pre-existing ASCII path did a bare host.lower(), which keeps it.

Leaving both as they were would have produced a branch-dependent authority:

input	ASCII branch	IDNA branch
https://xn--bcher-kva.example./p	xn--bcher-kva.example.	—
https://bücher.example./p	—	xn--bcher-kva.example

Same host, two spellings, two different @authority values — so a signer emitting the A-label form and a verifier deriving the host from a Host header carrying the U-label would compute different signature bases and every signature between them would fail to verify. That is precisely the silent canonicalization drift the single-algorithm design exists to prevent.

Three options were available, none of them free:

1. Strip once, before the branch (chosen). Both branches agree, and they agree with the designated normalizer. Costs a wire-visible change for FQDN-root URLs.
2. Detach and re-append around the branch. Preserves today's bytes exactly, but it is bespoke normalization inside canonical.py — which would make it the seventh host-normalizing implementation in the tree, the duplication fix(signing): reject malformed authorities, convert IDN hosts to A-labels #985 exists to reduce.
3. Reject a trailing root dot as a malformed authority. Unambiguous, but invents a rejection the spec does not state, and rejecting traffic the spec may require accepting is worse than the ambiguity.

What this issue is actually asking for

The spec should define root-dot handling and ship a vector for it. example.com. and example.com are the same DNS name; whether they are the same signature base is a protocol question, not an SDK question, and every implementation is currently guessing.

Note that the SDK could not simply add a local vector to settle it. tests/conformance/vectors/request-signing/ is vendored verbatim and pinned by SHA-256 in vector_manifest.json; test_vendored_tree_matches_manifest_exactly fails on extra files as well as modified ones, and its own message states the policy:

"Vectors are vendored verbatim from the spec; add the file upstream first, then re-vendor and regenerate the manifest."

That pin is #975/#980's whole point, so working around it locally would have reintroduced the drift those issues exist to stop. The behaviour is therefore pinned by an SDK-local test (test_trailing_root_dot_is_stripped_on_both_host_branches) which is explicitly marked as superseded once a real vector exists.

Suggested upstream ask (adcontextprotocol/adcp): add a root-dot-* case to dist/compliance/<version>/test-vectors/request-signing/canonicalization.json fixing whichever behaviour the spec wants, and state the rule in the @target-uri canonicalization steps alongside the existing scheme/port/path rules.

Impact

Low, but real. Affects only callers signing or verifying URLs whose host carries an explicit trailing dot. A new-SDK signer and an old-SDK verifier disagree for those URLs during rollout. Shipping as a minor (#985 is titled feat:) rather than a patch for this reason.

Related

• fix(signing): reject malformed authorities, convert IDN hosts to A-labels #985 — the PR that makes the change
• @target-uri canonicalization applies no IDNA A-label conversion, and the verifier does not reject raw U-labels #977 — IDNA A-label conversion (the change that forced the question)
• Vendored request-signing conformance vectors are incomplete, and the loaders cannot detect it #975 / test(signing): vendor the complete AdCP 3.1.8 request-signing vector set and pin it against drift #980 — the vendored-vector pin that prevents settling this locally

[bokelley]

Triage

Classification: Protocol question
Bucket(s): signing, cross-repo (neither label exists in this repo — flagged for label creation)
Status: deferred

What the experts said:

• ad-tech-protocol-expert: The SDK's strip-before-branch choice is the correct pragmatic fix for the IDNA consistency problem introduced by fix(signing): reject malformed authorities, convert IDN hosts to A-labels #985 — without it, example.com. (ASCII path) and bücher.example. (IDNA path) would produce different @authority values for the same host. Risk is low because trailing-dot Host headers essentially never appear in production HTTP traffic (browsers and modern stacks normalize them away). The open spec question is whether AdCP @authority follows WHATWG URL normalization rules (strip = normative) or RFC 3986 §6.2 wire-form (strip requires explicit justification per RFC 9421 §2.4). Only an upstream vector settles it; without one, a future TypeScript or Go implementation that reads RFC 9421 §2.4 literally could silently diverge.
• adtech-product-expert: Trailing-dot URLs are effectively invisible in production ad tech — no DSP/SSP integration guide documents or tests them. The rollout skew risk (new-SDK signer / old-SDK verifier) is real in the abstract but a compound improbability in any live integration. Deferring to the upstream spec with an SDK-local placeholder test is the correct product decision. Escalation priority: low.

My take: The SDK has made a sound interim choice — stripping once before the branch eliminates the branch-dependent authority divergence, aligns with the SDK's broader design (JWKS URI, revocation, key_origins all strip trailing dots), and is consistent with the designated normalizer. The remaining question belongs to the spec: AdCP should declare whether @authority follows WHATWG URL rules or RFC 3986 wire-form, and ship a root-dot-* vector in dist/compliance/<version>/test-vectors/request-signing/canonicalization.json.

Blocked-on: adcontextprotocol/adcp defining the spec rule and shipping a conformance vector — at which point test_trailing_root_dot_is_stripped_on_both_host_branches is superseded and the vendor/regenerate cycle closes this issue.

---

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

---

Generated by Claude Code