#780: Private State Tokens (formerly Trust Tokens)

Visit on Github.

Opened Oct 19, 2022

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.

Further details:

  • 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

Discussions

Discussed Nov 1, 2022 (See Github)

Dan: is this replacing 3rd party cookies?

Hadley: use ase to avoid fraud, but not cookies in the traiditional case

Peter: original design used zero trust cryptography. Client would go to the token issuer and send a nonce and the issuer would sign that, untwist it and get the signature. The signature can be verified but nobody knows what was actually signed. The signing site couldn't correlate the eventual bearer of the token with the person that got the token issued unless they used a unique key to sign that one token, and there were mitigations against having too many keys. They could use a small handful of keys to categorise users, but we're talking 3 to 5 keys over thousands of users. That was the original design. Looking for a change section.

Dan: early review

Hadley: some sense of how this has changed would be useful

Peter: +1

Dan: [leaves comment]

[Discussion about related IETF work]

Discussed Dec 1, 2022 (See Github)

Amy: one of their changes is that they have a spec now

Yves: Mozilla standards position?

Amy: deferred until Privacy Pass was done, no update yet

Yves: webkit

Hadley: seems like they are building on an earlier version of privacy pass that will need to be updated

Amy: ask them if we should wait to review until they've rebased their spec on updated privacy pass? (Given they say it will be a month)

Hadley: maybe this isn't the most useful time for feedback for them

Peter: seems reasonable to ask them. We did an early reivew of this a long time ago. This still feels like an early review.

Hadley: this is already in chrome 111? chrome status

Amy: nothing in PING repos

Peter: weird thing about redemption.. requiring additional information beyond the URL to make the request. They have a note in their explainer about the use of it on top level navigation. That's a potential future extension, seems like more of a core use case. Wondering if the redemption should be something more ambient in the browser, rather than something explicit. What's the use case for an explicit redemption on fetch? Why do they think that's useful?

Comment by @torgo Dec 1, 2022 (See Github)

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

Comment by @torgo Dec 1, 2022 (See Github)

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?

Comment by @dvorak42 Dec 12, 2022 (See Github)

The main changes are:

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.

Comment by @rhiaro Dec 12, 2022 (See Github)

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?

Comment by @dvorak42 Dec 12, 2022 (See Github)

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.

Comment by @plinss Dec 12, 2022 (See Github)

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.

Comment by @dvorak42 Dec 15, 2022 (See Github)

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.

Discussed Feb 1, 2023 (See Github)

Dan: we set it to proposed closed last week...

Hadley: i think we wanted Tess to have a look.

Dan: suggest we close and let Tess know.

Comment by @hadleybeeman Feb 8, 2023 (See Github)

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.