#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

2022-11-28

Minutes

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]

2022-12-12

Minutes

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?

2023-02-13

Minutes

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.