Create and write back SharedID in the shared app #1593

Summary

SharedID in the shared app: create one when the reader has none and storage.type is cookie, and write it back with <name>_cst, under SID-2 and SID-6; verified on Fastly.

Part of #1558, server-side identity on every adapter. Plan ID T13, planned in wave 6 (MVP: Fastly and Axum); priority P1, size M. Design: spec; order and dependencies: plan.

Requirements

WB-3 SharedID cookie

When SID-2 and SID-6 allow it, the server sets the SharedID cookie from the record if the request has none or a different value. When neither the record nor the request has one, the server creates a SharedID in the format Prebid writes (a UUID v4), stores it in the record and sets it the same way, because a browser may block Prebid.js from loading at all (DEC-7). It creates and writes back a SharedID only when the configured storage.type is cookie (Prebid's cookie&html5 counts as cookie): with html5 Prebid never reads the cookie, so a server-made SharedID would split the reader's identity (SID-3). It uses Prebid's storage name and the Domain Prebid writes with, is not HttpOnly, and is Secure; SameSite=Lax for one year. It keeps Prebid's <name>_cst companion consistent, since a missing or different one makes Prebid rewrite the cookie from script, which Safari caps. Prebid's extend with a pixelUrl keeps working alongside it.

SID-2 Opt-out

A _pubcid_optout cookie stops SharedID reads, storage, sending, creation and write-back. Prebid also reads the opt-out from localStorage, which the server cannot see, so the injected script copies a localStorage _pubcid_optout into the cookie (T20).

SID-5 Retention

The record keeps a SharedID for as long as the record lives, and the stored value wins over a different browser value. When neither has one, the server creates it (DEC-7, WB-3).

SID-6 EID consent

Reading SharedID into the record, storing it, sending it and writing it back each need EID permission (TCF Purposes 1 and 4, through the consent module's EID predicate in consent/mod.rs), in addition to EC permission and the SID-2 opt-out. EC permission alone (consent_allows_ec, Purpose 1) is not enough. Where consent is required but missing, permission is denied.

Current state

What the code does today, from the design's survey at the revisions it names:

• WB-3: no branch writes it.
• SID-5: main does this on Fastly (ec/kv.rs:134-174); Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2 #1488 keeps a cookie-read SharedID for 24 hours and lets the cookie replace it.

Acceptance criteria

• WB-3: Record present and cookie absent gives both cookies with those attributes
• WB-3: A consented first visit with no SharedID anywhere gets one created, stored and set, and a reader with _pubcid_optout gets none
• WB-3: With storage.type = html5 the server neither creates nor sets a SharedID
• WB-3: An equal cookie with a consistent <name>_cst gives no Set-Cookie
• WB-3: An equal cookie with a missing or different <name>_cst re-sets only the companion
• WB-3: Purpose 1 denied or _pubcid_optout expires both
• WB-3: Purpose 4 denied with Purpose 1 granted gives no Set-Cookie and leaves the browser's cookie alone
• SID-2: With _pubcid_optout present nothing SharedID-related is read, stored, sent, created or written, and a localStorage-only opt-out stops creation from the next request on
• SID-5: A stored SharedID survives a request carrying a different cookie value
• SID-6: On each supported adapter, with a populated record, an absent or different browser cookie, Purpose 1 granted and Purpose 4 denied, no SharedID is read, sent or written back

Dependencies

Blocked by:

• SharedID cleanup: legacy path, cross-source dedupe, re-filing, SID-6 gate, template-cache deny list #1584 SharedID cleanup: legacy path, cross-source dedupe, re-filing, SID-6 gate, template-cache deny list (new in this plan)
• One identity app in core for every adapter #1600 One identity app in core for every adapter (new in this plan)
• PR Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2 #1488 Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2

Blocks:

• Identity features pass on Axum from the shared app #1581 Identity features pass on Axum from the shared app (new in this plan)
• Identity features pass on Cloudflare from the shared app #1596 Identity features pass on Cloudflare from the shared app (new in this plan)
• EC route in the shared app, verified on Fastly #1598 EC route in the shared app, verified on Fastly (new in this plan)

Related pull requests

• Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2 #1488 Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2: must merge first.

  Fixes the plan asks of Add identity providers for ID5, LiveIntent, LiveRamp, ConnectID and UID2 #1488

  Take Run server-side identity collection on the Axum dev server #1566's 0a2a00aaf, which reads the SharedID name from managed_user_ids, defaults the source to pubcid.org and keeps the stored value (still open here: sharedid.rs:46-59, common.rs:94,110,129-136). Take 0c13d4272: the blanket reject_providers_without_a_kind (config.rs:348) makes ts config validate, push and diff reject every enabled provider. SID-6 holds for the provider path. LiveRamp's Custom ID waits on DEC-9, which gates enabling LiveRamp, not this merge. Answer its open threads.