Private State Tokens (formerly Trust Tokens)

[dvorak42]

Wotcher TAG!

I'm requesting a TAG review of Private State Tokens (formerly Trust Tokens).

The Private State Token API is used to transfer a limited amount of information across sites in a privacy preserving manner. It achieves this using the Privacy Pass protocol from the IETF working group. The Private State Token API can be considered as a web-exposed form of the Privacy Pass protocols.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/trust-token-api/blob/main/README.md
• Specification URL: https://wicg.github.io/trust-token-api/
• Tests: https://github.com/web-platform-tests/wpt/tree/master/trust-tokens
• User research: N/A
• Security and Privacy self-review²: https://docs.google.com/document/d/1KPa5OQtp-n6wmf5PTDNSd-pGP993sOtZfl0LbT5fopk/edit
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/trust-token-api/
• Primary contacts (and their relationship to the specification):
  • Steven Valdez (dvorak42), Google
  • Aykut Bulut (aykutbulut), Google
• Organization(s)/project(s) driving the specification: Google Privacy Sandbox
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Apple (likely defer until further updates to match privacypass): https://github.com/WebKit/standards-positions/issues/72
  • Mozilla (defer): https://github.com/mozilla/standards-positions/issues/262
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5078049450098688
• Previous Early Review: https://github.com/w3ctag/design-reviews/issues/414

Further details:

• [X] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: wicg (likely to move to antifraudcg in the near future)
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): probably WebAppSec
• Major unresolved issues with or opposition to this specification: We're not aware of major issues or opposition at this point, though we are awaiting further feedback from other browser vendors.
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

Previous review: https://github.com/w3ctag/design-reviews/issues/414

[torgo]

Hi @dvorak42 we're taking a look at this - can you please point us to a list of changes since the previous version we reviewed? That would greatly help. Can you let us know where you are in the IETF process, and also can you provide some further context on the information on additional multi-stakeholder feedback?

[dvorak42]

The main changes are:

• Addition of a Sec-Trust-Token-Lifetime header to limit the lifetime of redemption records (based on OT feedback).
• Removal of the signed outgoing request extension as it was complicated and unused during testing.
• Addition of a spec document (https://github.com/WICG/trust-token-api/blob/main/spec.bs, https://wicg.github.io/trust-token-api/index.html)
• Rename to Private State Tokens (and generalizing the API surface to support other types of Private tokens).

In the IETF, the privacypass protocol is reaching WGLC (to be turned into an IETF RFC) and should hopefully be done in the next month or so, we'll rebase parts of the PST specification on top of that, though there are a few features/extensions to that protocol that we'd like to have on top of/replace so will likely have some delta with that spec.

There's been some support during the OT from other companies and interest by Edge (https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/TrustTokenExtensions/IssuerRedemptionStatistics.md) though we haven't gotten strong signals on other browser engine support for the API.

[rhiaro]

In the IETF, the privacypass protocol is reaching WGLC (to be turned into an IETF RFC) and should hopefully be done in the next month or so, we'll rebase parts of the PST specification on top of that

Would it make sense for us to wait on doing a full TAG review, until these changes have been made?

[dvorak42]

I don't think waiting on those changes makes sense for the TAG review, the main change we'd pull in from the RFC version is a change to the crypto primitive used internally by the API, which isn't really web-exposed/doesn't affect the web side of the API. The other major change in the privacypass spec is a definition for triggering via HTTP authentication, however for PST we're not planning on supporting that method of using tokens initially and would continue to use the fetch API defined in the PST spec/explainer.

[plinss]

I'm curious why the decision to only send redemption records as explicit arguments to fetch. It seems to me that once a token is redeemed, it might make more sense to treat the redemption record as a 'cookie' (metaphorically, not literally a cookie) and send it automatically with all future requests, or at least give an API with the option to enable that.

[dvorak42]

The original reason was that since you could have multiple redemption records that you might want to send depending on the context, having the top-level site explicitly indicate which records to attach allowed for more explicit control of what was being attached to each request from the site.

Some extensions we've thought about is the top level site being able to indicate that all requests to specific origins should include RRs from a particular issuer (or the Optimizing redemption RTT where origins request specific tokens via HEAD headers), but at least during the initial experiments it wasn't a hard requirement for the API so we wanted to land the more explicit API before adding extensions to optimize the inclusion of redemption records.

[hadleybeeman]

We are looking at this at our W3CTAG face-to-face (Moon Base Alpha).

We see no reason not to go ahead with this, since you have helpfully answered our questions. We note that we have only reviewed the API, not the crypto primitive (which is out of scope), and that this still doesn't seem to have interest from Safari or Firefox.

Thanks, and let us know if we can help further.