Support Sourcepoint localStorage consent for Edge Cookie generation via GPP/US consent bridging

[ChristianPavilonis]

Description

Summary

Edge Cookie generation currently fails for sites using Sourcepoint when consent
is stored only in localStorage and not surfaced via the standard cookies Trusted
Server reads.

In our site, Sourcepoint stores US consent in localStorage under a key like:

• _sp_user_consent_36026

Example payload includes:

• full GPP string: DBABLA~BVQqAAAAAgA.QA
• applicable section IDs: [7] (usnat)
• consent granted state:
  • consentedToAll: true
  • consentedToAny: true
  • granularStatus.gpcStatus: false

Today, Trusted Server only extracts consent from:

• euconsent-v2
• __gpp
• __gpp_sid
• us_privacy
• Sec-GPC

As a result, when Sourcepoint consent exists only in localStorage, the server
sees no consent signal and blocks EC creation in regulated US states.

Current behavior

Given a request with cookies like:

• _aren_ab
• ArenaGeo=... → US / TN
• datadome=...

and no euconsent-v2, __gpp, __gpp_sid, or us_privacy cookie, EC generation is
denied.

This is expected under current code because:

1. ArenaGeo only influences jurisdiction detection
2. Tennessee is treated as a regulated US state
3. US-state EC gating currently allows EC only when one of these is present:
   • TCF Purpose 1 consent
   • us_privacy that does not opt out
   • and no Sec-GPC: 1

Even if we mirror Sourcepoint’s localStorage value into __gpp / __gpp_sid,
current US-state EC gating does not appear to use GPP US sections as an allow
signal for EC creation.

Relevant code

Consent extraction:

• crates/trusted-server-core/src/consent/extraction.rs
• crates/trusted-server-core/src/constants.rs

Consent gating:

• crates/trusted-server-core/src/consent/mod.rs (allows_ec_creation)

EC generation/finalization:

• crates/trusted-server-core/src/ec/mod.rs
• crates/trusted-server-core/src/ec/finalize.rs

Docs:

• docs/guide/edge-cookies.md
• docs/guide/ec-setup-guide.md

Problem

Trusted Server assumes consent will arrive via standard cookies/headers, but
Sourcepoint on this site stores consent in localStorage only.

This creates two gaps:

1. Transport gap
   The server cannot read browser localStorage, so no consent reaches the backend
   unless client code mirrors it into cookies/headers.
2. Semantics gap
   Even if Sourcepoint’s GPP data is mirrored into __gpp / __gpp_sid, current
   US-state EC gating does not use GPP US sections to allow EC creation.

Proposed solution

Phase 1: client-side mirroring

Add client-side logic to read Sourcepoint localStorage and mirror consent into
standard transport cookies:

• __gpp=
• __gpp_sid=

For the example payload:

• __gpp=DBABLA~BVQqAAAAAgA.QA
• __gpp_sid=7

Optional temporary compatibility bridge:

• derive and write us_privacy= for current server compatibility

Phase 2: server-side support for GPP US sections

Extend EC gating for Jurisdiction::UsState(_) so decoded GPP US sections can be
used as a valid consent signal for EC creation, instead of relying only on:

• TCF Purpose 1
• us_privacy
• Sec-GPC

Expected behavior

After a user accepts Sourcepoint consent:

1. client reads sp_user_consent* from localStorage
2. client writes __gpp and __gpp_sid
3. a subsequent Trusted Server-managed request includes those cookies
4. EC consent evaluation recognizes the US GPP signal
5. ts-ec / x-ts-ec can be generated when consent allows it

Acceptance criteria

Transport

• Sourcepoint localStorage consent can be mirrored into standard cookies
• __gpp and __gpp_sid are populated from sp_user_consent*

Server behavior

• Trusted Server recognizes GPP US sections as valid US-state consent input for
  EC gating
• allows_ec_creation() no longer requires us_privacy when equivalent GPP US
  consent is present
• Sec-GPC: 1 still overrides and blocks EC creation
• Existing TCF and us_privacy behavior remains unchanged

Tests

• Add tests for US-state EC allowance with GPP US section consent
• Add tests that GPC still blocks EC when GPP is otherwise permissive
• Add tests for deny/fail-closed behavior when no usable consent signal is
  present

Notes

This should likely be implemented as a standards-first path:

• prefer __gpp / __gpp_sid
• keep us_privacy only as backward-compatible fallback

This will make TS work better not only with Sourcepoint, but with other CMPs
that expose US consent through GPP rather than legacy us_privacy.