Add the client-set Edge Cookie value path

[jwrosewell]

This description was updated on 7 October 2026, and on 8 October for the merge of main at 182fdf4. The branch now carries
the refreshed permission model (#1045 at fd51fe8) and, through it, main
at 182fdf4. Since the last version of this text:

1. What an operator selects is a module. The demonstration module is
   selected with [ec] module = "client_fixed", the trait that gains
   resolve_from_client is EdgeCookieModule, and every name this pull
   request adds says module, as the seam's names do. Through the permission
   model the branch carries the module name rule, under which a module from
   a crate is named by its folder below crates/, and
   [permission-signal] modules. client_fixed is one of core's own
   bare names and is unchanged.
2. The resolve endpoint answers with the module the request's own context
   selected, rather than building one again. On Fastly the composition root
   threads the built-in module into the request, so the rebuild found the
   built-in name claimed twice and answered 500 for a valid selection, where
   it should answer 204 for a module that creates nothing from a client post
   and 200 for client_fixed. Two tests read a context with the module
   threaded through the services, as Fastly does, and fail without the
   change.
3. A resolve_allowed_origins entry that is not a bare origin (http or
   https, a host, a port if there is one, and nothing else) is refused
   when the settings load and by ts config validate and ts config push,
   with a message naming the entry and what is wrong with it, rather than
   being kept and matching nothing, which answered every resolve from that
   origin with 403.
4. The old client-fixed spelling is no longer refused by name. No
   configuration uses it, and it now fails as any unknown implementation
   does, with the message listing the implementations the deployment has.
5. The endpoint writes the cookie with set_ec_cookie, the one writer every
   Edge Cookie goes through. Its own copy of that function is gone.
6. The tests that repeated one arrange are tables, and three cases the
   earlier text said were not driven now are: an identifier outside the
   cookie bounds answers 400 and leaves no cookie and no identity-graph row,
   a failed identity-graph write answers 503 with no cookie, and a
   Content-Length over the limit is refused before the body is read.

The commits since the merge of #1045 (20af33c) are c4722aa (bare
origins), c87a986 (the selected module answers), 3b30859 (the old
spelling), 8ae43d1 (one cookie writer), 7de2f18 and bbda299 (the
resolve tests), c91b8c6 (the demonstration module's tests), b63eabc
(the merge of #1045's CI fixes) and ff56a5f (the client resolve path says
module).

On 7 October, e3aeeba restored the icu_provider crate name in the
permissions inspector's lockfile, which the merge of #1045 had turned into
icu_module. The inspector built regardless, because its build script runs
cargo without --locked and cargo re-resolved the crate each time, and
cargo check --locked now accepts the file as written. 9a37728 is the
merge of #1045 at fd51fe8, which brings the module name rule and the
permission signal modules named by their crate folders.
6b9f52b is the merge of #1045 at c0a0f3a, which brings comment and guide
wording from the three pull requests below and #1043's statement of what
normalize_id_for_kv decides, with its test. This pull request's own
files are unchanged.
59660c4 is the merge of #1045 at 613cd18, which brings #1043's wording
of the identity graph's comments as device records, not person records.

Stacks on the permission model (#1045), and depends on it because the resolve
endpoint applies the same permission gate as organic generation. Through the
stack this pull request also depends on the Edge Cookie module seam (#1043),
whose EdgeCookieModule trait gains the client resolve method here. The
stack has six pull requests (#1043, #1044, #1045, #1046, #1047, #1094), each
targeting main, with this one fourth, and the first five decompose #838 as
requested in the #986 review.
Compare split/3-permissions with split/4-client-resolve
to see only this pull request's change.

The design specs for the series are carried by the spec pull request (#1084).
The spec for this pull request is
2026-07-30-client-cycle-ec-resolve-design.md,
the threat-model draft revised to the implemented state. Its revision record
maps each requirement to what v1 implements and what deliberately waits for the
first vendor scheme.

Why this path matters

A client-cycle module establishes the identifier through a browser round
trip. The page script obtains or derives a value, which for a real vendor is a
signed envelope from that vendor's identity system, posts it to
POST /_ts/api/v1/ec/resolve, and the module verifies that value before the
edge sets it as the Edge Cookie. The vendor Edge Cookie module proposed in the
51Degrees module issue (#1072) works client-side by design, so this endpoint is
on the series' critical path rather than deferred.

What this pull request does

• EdgeCookieModule gains resolve_from_client with a default that creates
  nothing, so server-side modules are untouched.
• The resolve endpoint enforces the same rules as organic generation plus its
  own. The permission gate applies unchanged, being the module's complete
  declaration rather than a hard-coded storage check, and the module's
  response headers pass the same reserved-surface check before any is kept. The
  request must carry an Origin on the publisher's domain (403 otherwise) and
  a text/plain or application/json body (415 otherwise, 413 over 64 KiB,
  refused from the advertised Content-Length before the body is read). A
  created identifier must fit the global identifier bounds (400) and must not
  silently replace a different identity already on the request (409).
• The endpoint answers with the module the request's own context selected
  when the page was served, so a module an adapter threads into the request
  is the one that verifies the posted value.
• A created identifier is persisted to the identity graph before the cookie is
  set, keyed by the module's canonical form, so withdrawal reaches a
  client-set identity the same way it reaches an edge-created one. With no
  graph available the endpoint sets no cookie at all, which is stricter than
  organic generation, where the identifier is kept and only the row write is
  skipped. A graph write failure answers 503 with no cookie. A closed
  permission gate, no configured module, no graph, or a module that creates
  nothing answers 204 with no Edge Cookie. The module's own response headers
  go out only with the 200 that sets the cookie, or with the 204 when the
  module creates nothing. Every response the handler builds carries
  Cache-Control: no-store, and a module or configuration error goes to the
  adapter's error response instead.
• The Edge Cookie stays HttpOnly. A non-HttpOnly companion marker cookie
  (ts-ecr=1, no identity content) tells the page script a resolve succeeded,
  fixing the earlier defect where the script checked for a cookie it could
  never read and so posted on every page view. The marker expires together with
  the Edge Cookie on withdrawal, and when the request carries an Edge Cookie
  the selected module does not own, so a switch between client-cycle modules
  resolves again. A Rust test checks that the marker name and the
  demonstration's fixed word match the page-script source.
• [ec] resolve_allowed_origins lists the extra origins the endpoint accepts
  beyond the publisher's own, each a bare origin, checked when the settings
  load.
• The client_fixed demonstration module is compiled only behind the
  client-fixed-demo cargo feature, and production builds reject the selection
  at startup. A fixed shared word is not an identity. The demonstration
  module's cookie carries the registry code (cfix~an-ec), so even
  demonstration identities are module-namespaced. The cargo feature keeps its
  own spelling, because a build feature is not something a deployment writes
  in trusted-server.toml.
• The Fastly adapter routes the endpoint with the same bot-gated identity graph
  as generation. The other adapters deliberately do not route the endpoint yet,
  matching identify and batch-sync, which need the same platform key-value
  wiring those adapters lack. The Spin adapter's route list records it.
• The full anti-replay reservation design from the spec is deliberately not in
  v1. The reservation design needs the real vendor envelope's unique id and
  session binding, and the spec keeps the design verbatim as the bar for that
  implementation.

How it was verified

The head this pull request shows now is e7623de78, which merges #1045 at 0afd715c5 and, through it, main at 182fdf4 into 59660c468. The merge brings the ts dev lint domains and ts dev install-hooks commands (#733) and a design document (#930), and changes none of this pull request's own code. No dependency of core or of an adapter changed version, and the one line of core the merge touches gains a comment. On e7623de78 these ran locally on Windows: cargo fmt --all --check, a locked dependency check (cargo tree --locked) and the core suite natively (3,140 tests).

59660c468 is two merges of #1045 above
9a3772871, which bring comment and guide wording, the identity graph's
comments, one doc comment and one test. On 59660c468 these ran locally on Windows: cargo fmt --all --check,
Clippy with warnings denied on all four adapters and the five permission
signal crates, the core suite natively (3,140 tests), the five permission
signal crates' own tests (55 tests), and the docs lint, Prettier and VitePress
build. On 9a3772871 the wider set ran locally, being the core suite under
Viceroy (3,377 across the test binaries the Fastly alias runs, the Fastly
adapter's included), the Axum (123 tests, the five permission signal crates
included), Cloudflare (56) and Spin (90) adapter suites, the cross-adapter
parity suite (17) and the permissions inspector's wasm build, and CI runs
all of them on this head. The CLI tests, the browser integration tests and
the Fastly Edge Cookie lifecycle test run only in CI.

CI on e7623de78: every check passes, being Run Tests, Run Format, Integration Tests, Permissions Inspector and CodeQL Advanced, with the Fastly Edge Cookie lifecycle test in the integration run. Run Tests passed on its second attempt. The first failed in one test, collects_gpt_slot_from_local_fixture, on a browser launch timeout, which #1256 describes.

Endpoint tests in
crates/trusted-server-core/src/ec/resolve.rs
cover the origin, content type, advertised and actual body size, identifier
bounds, conflict, no-graph, failed graph write, marker and threaded-module
behaviors, and client_set_value_round_trips_through_the_ec_scenario drives a
client identifier through deferral, resolve, cookie set and verbatim
read-back.

References #778. Decomposes #838. Spec baseline from #986.

[aram356]

The sequencing discussion for this series is on #1084. This PR is superseded rather than rejected. The design in §3.6 is accepted and most of the provider work carries over onto the reordered base. See #1084.