Description
Hi @scottlow, thanks for the shout-out to our Trust Token work in the WebPrivacyAuditing explainer. I agree that parts of it (especially request signing) could be a good fit for the use case you mentioned, which is essentially about being sure that a cookie you see multiple times really came from the same browser, not from an impersonator.
Regarding your excellent question about not creating new identifiers: note that the crypto-signed view or delete requests don't need to include the actual cookie. They could instead include a signed crypto-hash of the cookie (along with e.g. its domain name and some replay-prevention mechanism like a one-day-granularity timestamp). Now a company that already has data keyed by my cookie can be sure I've asked them to delete it, but a company with no data keyed by that cookie doesn't learn anything about what I'm asking for.
It occurs to me that similar underlying crypto might also help with your "honor users' choices for data control" auditing goal. If the browser knows what choices a user has made (e.g. if some consent prompts pass through browser control), then the browser could send a user-gave-consent signal that is signed with the same private key used in signing other cookied outgoing requests. That means that when a company is audited, they could be asked for cryptographic proof that the browser believed the user consented — which seems usefully better than just taking everyone's word for it that consent was given.