Is This Spec in a Conceptual Transition from TT to PST, or Just Renamed?

[thegreatfatzby]

I'm trying to understand the extent to which Private State Tokens is in state of "conceptual transition", having gone from Trust Tokens to Private State Tokens, and so is open to modifying some design limitations to accommodate "a broad set of web trust related use cases". As currently stands, the registration and 2-issuer limit will limit PSTs ability to solve these cases as a general Web API.

Trust Tokens

The motivating use case of "Trust Tokens" was quite specific, and so I think there are a few implicit assumptions reflected in the design:

• A top level site would likely only need one, or certainly few, "not a bot" providers, and change them infrequently.
• Relatively few "not a bot" providers would ever exist, and the list of vendors available would change infrequently.
• Having to refresh the set membership periodically is fine, even desirable.
• Kind of the same as previous, but false negatives are OK.

Which would support a few things:

• Need for registration (seems that is going away?)
• Limit of 2 issuers per top level site.
• The token architecture, with issuing and redeeming, overall.

Private State Token: Motivation

So in the new PST Motivation section, there seems to be a suggestion of, even a call for, this being part of a more general Privacy Sandbox tool/Web API (highlights mine):

Segmenting users into very coarse sets satisfies other use cases that establish web trust as well. For instance, sites could use this as a set inclusion primitive in order to ask questions like, “do I have identity at all for this user?” or even do non-personalized cross-site authentication ("Is this user a subscriber?"). While we encourage exploration into solving a broad set of use cases, Private State Tokens should only be utilized for anti-fraud, anti-abuse, web security, or other web trust and safety purposes. PSTs are not intented to convey artibrary cross-site information, such as user demographic information for ad targeting or measurement.

New PST Motivation Limited by Old TT Implicit Assumptions and Constraints?

The set of use cases related to web trust is broad, and so the first two constraints will limit what sites/services can do to "explore a broad set of web trust related use cases". I'm unclear if this is intentional, or in a state of transition.

By way of example, I've been thinking about using a PST to solve the "Persistent Opt Out" problem we're now having with the move to CHIPS. Opting out of a cross domain web service like an ad tech platform, or other tracking entity, seems very much in line with the PST Motivation listed above. However, I'd see a couple of issues that seem related to the original intent:

• Registration: Even just this class of use cases would invalidate the first two assumptions mentioned above (rate of change, number of vendors). Having to register every 6 months and potentially hit false negatives due to a missing registration would be bad. Since the registration requirement is maybe going away, I'll just put here that I agree with the statements in that issue and look forward to clarification on that.
• False Negatives: The limit of 2 issuers per site wouldn't be tenable, as false negatives wouldn't be OK. A user who opted out of multiple ad tech platforms via something like privacy.xandr.com, would end up having those opt outs inconsistently respected per Top Level Site depending on the order in which code executed.

The 2 issuer limit would get even less tenable if creative solutions for suggested ideas like "do I have identity at all for this user" and "Is this user a subscriber" came out to contribute to more 0-auth'y type ideas.

So I'd like to understand how you guys are thinking about the future state of PST in particular, which is related to my broader "coarse sets for Privacy Sandbox" question over here.