Hadley: I would like to ping the requestor again and see where they are now...

[disussion on trust tokens]

Hadley: possbility for misuse ... totalitarian govts...

Peter: concern of being able to categorize people based on metadata from the tokens... De-anonymization ... e.g. sign in to cloudflare sign-in with google... Cloudflare knows you're using google. Trust tokens could be used to allow anonymous access.

Hadley: it looks like after that initial discussion they are working on it...

Peter: as I recall there are mitigations...

Hadley: Mozilla supprotive of the ideals and goals but needs more securty analysis...

Amy: user activation at issuance of the token - I can't picture what that would look like. https://github.com/WICG/trust-token-api#mitigation-dynamic-issuance--redemption-limits

[we left more feedback on the issue and are waiting for response...]

Dan: is this in privacyCG?

Tess: no. WICG.

Dan: explainer updated.. rereview?

Hi @csharrison @dvorak42 - we're picking this up again at our virtual f2f this week. It looks like this work is ongoing in WICG. Can you provide any further updates? Any response to @martinthomson's message above? Should we be re-reviwing? If so can you let us know what's recently changed in your design?

Dan: sending message to Chris Harrelson - will report back at plenar

Peter: looks like we're waiting for input from them

Tess: update a month ago about an update to the explainer that should land.. they did make three changes in august but not to the explainer

Peter: Let's check in in a couple of weeks, and if not, face-to-face

Tess: waiting for an update from them

Dan: something new for us to review. Should bring this to attention of privacy tf

Hadley: confused about how site and ua are interacting. Is limit imposed by the spec or by the ua? How does the ua get to change the site's limit?

Dan: reference to privacy principles that is in a private repo that I haven't seen before..

Hadley: this goes through first part identity which ties into FPS.. but says third parties can be allowed access to a first party identity.. first party gets to decide with which third parties to share the identities of the user.. user should be in control of that rather than the first party.. concerned there may be some assumptions underpinning the broader issue that we would like to discuss.

Dan: i want to understand the standing of that document, the people working on trust token obviously think it has some standing. I think it may be superceded by the work Jeffrey did on the privacy threat model which has now become part of the privacy princples doc in the task force. If that's the case we should be getting those folks in trust token to reference our document. Even though it's hardly done it feels more comprehensive.

Ken: new doc called privacy framework

Dan: I asked whether the privacy framework doc could point to the privacy principles doc. Jeffrey Yaskin made a PR to do that. Good sign. I was unclear what the other privacy principles doc was that they were pointing to, apparently a Chrome one, better to refer to a more community driven one.

Ken: no spec yet?

Dan: we closed the captchas are horrible issue on the basis this is being worked on

Tess: one of the things is that it depends on the privacy pass stuff at ietf. I can't evaluate the crypto properties of that stuff. I would feel better if I saw some independent analysis of it by someone who does understand cryptography. I assume that's already happened and they can just link us to it.

Peter: i recall this was based on zero knowledge proof crypto

Tess: mozilla's position on privacy pass is 'defer', states they defer until the protocol and novel crypto principles have had more thorough security analysis. I'll quote that in a comment.

Dan: where are they talking about doing this work? raises comment

Peter: explainer is in wicg

Dan: then where does it go?

Peter: I see Hadley opened a couple of issues in their repo... two years ago. Which have been responded to but still open

Hadley: feels like there's still a situation where the user ends up having to choose a token issuer that isn't reputable.. I take that back, if the site has narrowed down the list of token issuers they will trust the worst thing it can do is track the user across other properties that are controlled by the same site.. I guess that is more of a privacy compromise than is possible just from the issuing site. I don't feel like the answer has been fully bottomed out. Did they flesh out the use cases? I'd like more time to dig into this.

Dan: there was a response to us - left comment and we'll talk about it next week.

Dan: one of the quesitons was to do with trusttoken being based on top of privacypass, an ietf spec. It was not clear what mozilla's disposition toward privacypass is. I marked it as a potential multistakeholder issue. They responded - looks on track... not clear which bits will get standardised... maybe webappsec after incubation. My sense is that addresses the issues we've raised. Maybe mark as satisfied with caveats and close?

Amy: worth asking to open a new review when they have a concrete spec

Peter: agree

Hi - thanks for the chance to give this important work an early review.  We're largely happy with the design and approach.  We're still concerned about the multi-stakeholder issuee and the dependency on PrivacyPass. We'd like the opportunity to review again when the spec is more concrete. Can you please either open a new issue or ping us and we can re-open this one.  In the mean time we're closing this.