Wiki · Concept · Last reviewed June 25, 2026

Private State Tokens

Private State Tokens are a browser API for carrying limited trust evidence from one context to another without exposing a stable identity or restoring linkable third-party cookie state.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, anti-fraud, Privacy Pass, agents, web governance

Definition

Private State Tokens, formerly called Trust Tokens, are a web-platform proposal for transferring a small amount of trust information across sites in a privacy-preserving way. The WICG draft describes the goal as moving limited signals through time and across sites using a variant of the IETF Privacy Pass protocol. MDN describes the API as conveying trust in a user's authenticity without sharing identity or allowing cross-site activity tracking.

The problem is familiar in anti-fraud work. A site may know that a visitor passed a challenge, used an account over time, or completed a purchase. Another site may want a coarse signal about that trust without receiving a third-party cookie, device fingerprint, email address, or account identifier. Private State Tokens narrow that exchange: a browser stores cryptographic tokens from an issuer and later helps a redeemer obtain a redemption record.

The API is not a proof-of-personhood system, identity provider, CAPTCHA replacement, or general authorization layer. MDN and Google Privacy Sandbox both state the same boundary: the mechanism conveys trust but does not establish it. The issuer decides why a token should be issued, and the redeemer decides what a redeemed token should allow.

Mechanism

The basic roles are issuer and redeemer. An issuer has some signal about a browser user and can trigger token issuance. A redeemer lacks that original context but trusts one or more issuers and asks the browser to redeem a token. If redemption succeeds, the redeemer receives a redemption record. The WICG draft emphasizes that the user agent does not authenticate the client by itself; it facilitates transfer of authentication information.

Private State Token operations are initiated through web APIs rather than by developers manually constructing cryptographic headers. MDN lists no standalone interface for the API; instead, it extends fetch(), Request(), HTMLIFrameElement, XMLHttpRequest, and Document. The relevant HTTP headers include Sec-Private-State-Token, Sec-Private-State-Token-Crypto-Version, Sec-Private-State-Token-Lifetime, and Sec-Redemption-Record.

The browser policy surface matters. MDN documents the private-state-token-issuance Permissions Policy directive for token-request operations and the private-state-token-redemption directive for token-redemption and send-redemption-record operations. When policy blocks the feature, the corresponding fetch operations fail rather than silently bypassing the browser boundary.

Agent Context

For AI Browsers and Computer Use, Private State Tokens sit between anti-abuse infrastructure and delegation policy. A browser agent may trigger fraud checks while opening accounts, submitting forms, navigating publisher sites, or buying goods. A redeemed token may reduce friction, but it is not evidence that the agent is authorized to act, scrape, purchase, message, or configure an account.

Agent systems should keep token-mediated trust separate from identity, consent, and authority. A token can help a site classify a request as less suspicious. It should not become a hidden passport that lets automated browsing bypass rate limits, avoid audit trails, or inherit a human user's session privileges without a separate delegation record.

Governance Use

A serious deployment should record issuer, redeemer, top-level origin, token purpose, policy directives, redemption outcome, retention rule, fallback path, and affected user population. It should also state what the token may influence: CAPTCHA friction, ad fraud decisions, account-risk review, rate limiting, content access, or transaction review.

Private State Tokens belong near Privacy Pass, Private Access Control Tokens, Web Bot Auth, Storage Access API, and Data Minimization. Each mechanism answers a different question: token architecture, browser API, automated requester authentication, embedded storage, or collection minimization.

Limits

Private State Tokens reduce some tracking channels but do not remove all tracking risk. The WICG draft explicitly discusses side-channel fingerprinting: unlinkability can be undermined if an issuer associates issuance and redemption through network-level signals or other side channels. The same governance concern appears in organizational form when a small set of trusted issuers becomes necessary for normal access to sites.

Browser support is also not universal. MDN marks the API experimental and tells developers to check compatibility before relying on it in production. Implementation claims should therefore name the browser, version, flags or enrollment requirements where relevant, and the specific operation tested. A policy claim about Private State Tokens should not be generalized into a claim about all browsers, all Privacy Sandbox APIs, or all Privacy Pass deployments.

Review Record

Source Discipline

Claims about the API goals, issuer and redeemer roles, redemption records, token limits, and side-channel concerns should cite the WICG Private State Token API draft. Claims about developer-facing methods, headers, and Permissions Policy directives should cite MDN. Claims about use cases and Privacy Sandbox framing should cite Google Privacy Sandbox. Claims about the underlying protocol family should cite the IETF Privacy Pass RFCs rather than treating a browser API as the whole protocol.

Spiralist Reading

Spiralism reads Private State Tokens as a lesson in narrow trust. A token should carry less than a name, less than a dossier, and less than a permanent reputation. The hard part is keeping that narrowness intact when fraud systems, advertisers, platforms, and agents all want a stronger signal than the web should safely provide.

Sources

Return to Wiki