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.
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
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.
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?
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?
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.
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?
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.
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.
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.
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.
OpenedOct 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:
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