Summary
Remove the legacy consent_store KV persistence path and make ec_identity_store the only KV-backed EC/consent lifecycle store.
Current deployments can run without consent_store, and normal request/auction flows do not read from it. Consent decisions are built from request cookies/headers/geo in EcContext, while identity state and withdrawal tombstones live in ec_identity_store.
Current behavior
consent_store is still exposed in config:
crates/trusted-server-core/src/consent_config.rs
trusted-server.toml
fastly.toml
- The consent pipeline still has legacy KV fallback/write helpers:
crates/trusted-server-core/src/consent/mod.rs
crates/trusted-server-core/src/storage/kv_store.rs
- Normal EC context creation passes
kv_store: None, so the consent KV fallback/write path is not active:
crates/trusted-server-core/src/ec/mod.rs
- Auction uses in-memory request consent from
EcContext, not consent_store:
crates/trusted-server-core/src/auction/endpoints.rs
- The only live
consent_store touchpoint appears to be best-effort deletion during consent withdrawal:
crates/trusted-server-core/src/ec/finalize.rs
Proposed cleanup
- Remove
consent_store from consent configuration and sample/local config.
- Remove consent KV fallback/write plumbing from
ConsentPipelineInput and build_consent_context.
- Remove or quarantine
crates/trusted-server-core/src/storage/kv_store.rs if it has no remaining callers.
- Remove best-effort
consent_store deletion from EC finalization; keep ec_identity_store withdrawal tombstones as the authoritative revocation marker.
- Update/remove tests that assume a configured/missing
consent_store behavior.
- Update docs/comments to clarify:
- live consent comes from request cookies/headers/geo;
- EC identity lifecycle and withdrawal state live in
ec_identity_store;
- there is no separate consent KV store.
Non-goals
- Do not add all legacy consent-store fields to
ec_identity_store unless there is a concrete product requirement for persisted consent fallback.
- Do not change auction consent gating behavior.
- Do not change EC tombstone semantics.
Notes
ec_identity_store currently stores a minimal consent snapshot (tcf, gpp, ok, updated) plus identity graph state. The legacy consent_store stored additional fields such as us_privacy, gpc, jurisdiction, gpp_section_ids, raw_ac_string, and a fingerprint. Those are still important as live request consent concepts, but they are not currently used as persisted runtime state.
Summary
Remove the legacy
consent_storeKV persistence path and makeec_identity_storethe only KV-backed EC/consent lifecycle store.Current deployments can run without
consent_store, and normal request/auction flows do not read from it. Consent decisions are built from request cookies/headers/geo inEcContext, while identity state and withdrawal tombstones live inec_identity_store.Current behavior
consent_storeis still exposed in config:crates/trusted-server-core/src/consent_config.rstrusted-server.tomlfastly.tomlcrates/trusted-server-core/src/consent/mod.rscrates/trusted-server-core/src/storage/kv_store.rskv_store: None, so the consent KV fallback/write path is not active:crates/trusted-server-core/src/ec/mod.rsEcContext, notconsent_store:crates/trusted-server-core/src/auction/endpoints.rsconsent_storetouchpoint appears to be best-effort deletion during consent withdrawal:crates/trusted-server-core/src/ec/finalize.rsProposed cleanup
consent_storefrom consent configuration and sample/local config.ConsentPipelineInputandbuild_consent_context.crates/trusted-server-core/src/storage/kv_store.rsif it has no remaining callers.consent_storedeletion from EC finalization; keepec_identity_storewithdrawal tombstones as the authoritative revocation marker.consent_storebehavior.ec_identity_store;Non-goals
ec_identity_storeunless there is a concrete product requirement for persisted consent fallback.Notes
ec_identity_storecurrently stores a minimal consent snapshot (tcf,gpp,ok,updated) plus identity graph state. The legacyconsent_storestored additional fields such asus_privacy,gpc,jurisdiction,gpp_section_ids,raw_ac_string, and a fingerprint. Those are still important as live request consent concepts, but they are not currently used as persisted runtime state.