01:42:14 RRSAgent has joined #trusttokens 01:42:14 logging to https://www.w3.org/2019/09/18-trusttokens-irc 01:42:21 RRSAgent, make logs public 01:42:28 koalie has changed the topic to: https://w3c.github.io/tpac-breakouts/sessions.html 01:42:30 koalie has left #trusttokens 08:37:13 RRSAgent has joined #trusttokens 08:37:13 logging to https://www.w3.org/2019/09/18-trusttokens-irc 08:37:16 Zakim has joined #trusttokens 08:37:20 present+ 08:37:23 kleber has joined #trusttokens 08:37:24 Scribenick: toml 08:37:25 present+ 08:37:27 scribenick: toml 08:37:28 Meeting: Trust Tokens 08:37:36 present+ 08:37:56 kleber: Trust Tokens are an API from Chrome's Privacy Sandbox 08:38:25 …: history: build on Cloudflare's Privacy Pass 08:38:29 -> https://github.com/dvorak42/trust-token-api Trust Token Explainer 08:38:30 blassey has joined #trusttokens 08:38:36 …: want to extend to new uses in this privacy world 08:38:43 MasayaIkeo has joined #trusttokens 08:38:51 …: goal is to help prevent fraud & abuse 08:39:07 …: today, this involves detecting patterns of malicious behavior 08:39:17 dave has joined #trusttokens 08:39:20 …: if you can't recognize people, that ability vanishes 08:39:28 weiler has joined #trusttokens 08:39:43 johnwilander has joined #trusttokens 08:39:44 …: this is an attempt to retain some spam/fraud-fighting capabilities while also removing identification/tracking 08:39:58 …: core tech: blinded tokens which are crypto magic 08:40:24 …: an issuer mints tokens signed with a cryptographic key in a ritual between browser and issuer 08:41:32 toml: Did you mean "indistinguishable from any token signed with the same key" 08:42:00 ...I think they are distinguishable from one another, but you can't tell which one was emitted with a given issuing event 08:42:14 wseltzer has joined #trusttokens 08:42:41 toml: They are distinguishable, but not correlatable (across different sites) 08:43:00 …: tokens are cryptographically guaranteed to have been issued by the issuer, but each token 08:43:58 kleber: tokens are unique, but the issuer doesn't know which tokens it's issued, only how many it's issued and redeemed 08:44:13 [some clarification of token primitive] 08:44:42 Chair: Michael Kleber 08:44:44 kleber: tokens represent one bit of information: "at some point in the past you trusted me" 08:44:53 (Ian likes "a message to its future self" :) 08:45:09 …: way for issuer to send a message to self in future, and message is "you trust this person" 08:45:27 …: ex banks might issue tokens to their legit customers 08:45:37 …: or Google might give them to longtime search users 08:46:01 …: original use case was to represent having completed a CAPTCHA for anonymous user (via Tor) 08:47:04 …: Tor users saw dozens of CAPTCHA request on Cloudflare. TT/PP give you a stock of tokens whenever you complete a CAPTCHA, and then you can spend them to avoid future CAPTCHAS for a while 08:47:10 …: fine when there's one issuer 08:47:28 …: want this to be a web standard where many people can issue tokens in different cases, and no need to use an extension 08:47:52 …: needs some limits, imagine 100 issuers — which of those you're holding tokens from might constitute an ID 08:48:10 …: so some limit on how many issuers you can be asked to pend tokens from on the same site 08:48:27 tony: is this using any hardware based stuff for key storage 08:48:38 kleber: all important crypto is server side 08:48:44 tony: platform crypto? 08:48:47 kleber: yes 08:49:04 …: some browser crypto needed to verify the ZKP non-uniqueness key 08:49:12 tony: so what does it use today? 08:49:38 kleber: platform crypto rn. no in-browser/js impl. no webcrypto RN, who knows the future. 08:49:54 kleber: second capability for our use case: ads! 08:50:02 …: we want to avoid ads fraud 08:50:06 …: next slide please 08:50:15 …: ad companies work hard to fight fraud 08:50:23 …: want to keep doing that without 3p cookies 08:50:56 …: once you've been given and redeemed a trust token, it'd be useful for your browser on the redeeming site to be able to make requests with a proof of that trust 08:51:24 …: present token back to google as verifier, google passes back certificate indicating trust from google on NYtimes 08:51:43 …: then you have a persistent gesture of trust 08:51:59 …: persistant keypair used for this session transaction 08:52:07 tony: not bound to http session? 08:52:09 q? 08:52:16 kleber: no, more like cookies? 08:52:22 +q to ask about certs 08:52:26 tony: how scoped? 08:52:34 kleber: haven't decided yet 08:53:08 …: probably origin tho? IDK? just use more tokens on more domains. 08:53:18 scribenick: Ian 08:53:25 toml: I want to review the transaction flow you outlined. 08:53:41 ...I'm a browser; google issues trust tokens to me; I have them in the browser and visit news.example. 08:53:59 ...they say "I want a trust token; we accept providers, A, B, and Google" 08:54:05 ....the browser gives a trust token and then google verifies? 08:54:28 Michael: Plausible but we were thinking of a different flow 08:54:35 ...browser asks news.example with a cert 08:54:51 toml: So when presented with a challenge from the news site, the browser does a redemption operation on the issuer site 08:55:21 Michael: You provide a trust token (to the issuer), as well as intended scope (news.example), and if you want to use the feature we were discussing, you bind it to a fresh key pair 08:55:52 toml: You take a pluripotent token and convert it to a scoped cert with a lifetime...and you use it on the site you are visiting, but the only thing it identifies is "I just redeemed a token" 08:56:08 ...and when the user agent decides it's time to clear state, 08:56:27 ..then a new request has to happen. That could happen N times with the identity provider (for N tokens) before a re-auth is required 08:56:33 scribenick: Toml 08:56:55 kleber: looking for feedback here 08:57:18 …: deanon risk exists even though it's 1 bit at a time 08:57:46 btidor has joined #trusttokens 08:57:47 …the sort of attacks are exactly the ones you'd expect 08:58:23 …i'm a first party you visit regularly, and i ask for many tokens from different providers; eventually, they can produce a cross-site id from those bits 08:58:48 …so you need to box the idp selection per site: can't change providers very often 08:59:04 …maybe if they change idps, you need to clear info about that site to avoid leakage 08:59:55 …likewise everything about tokens being fungible is dependent on a key being used to sign and redeem: malicious issuers could use unique keys for each visitor making a fungible token into a unique id 09:00:22 urata_ has joined #trusttokens 09:00:29 …so like at redemption time you can ask the idp what keys it uses, and it can only tell you a couple of keys so you're not bucketed any more narrowly than that 09:00:46 ???: so the issuer could use certain keys per ip? 09:00:53 melanierichards has joined #trusttokens 09:01:04 kleber: recognizing the user lets them do that 09:01:36 ???2: another attack surface — potentially revealing which IDPs you rely on 09:02:01 kleber: if you're not affiliated with the idps that a site trusts, then maybe you get a bunch of challenges 09:02:07 …seems unlikely 09:02:25 tony: is there crypto agility in this? 09:02:49 I have made the request to generate https://www.w3.org/2019/09/18-trusttokens-minutes.html Ian 09:02:53 ???3: the voprf spec is an individual draft submitted in the IETF 09:03:07 …not adopted yet 09:03:16 tony: pointer to the internet draft? 09:03:27 s/???3/Brad_Lassey 09:04:07 s/???3/Brad_Lassey/g 09:04:13 toml: there are also way old implementations of blind tokens with no ip implications imo 09:04:14 q+ 09:04:18 ack toml; 09:04:21 ack toml 09:04:21 toml, you wanted to ask about certs 09:04:32 https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/ 09:05:05 ben: how does issuance work? a first party with lots of confidence in a user. for a payments use case with many different sources of trust? can you use that? 09:05:13 kleber: probs not, tbh 09:05:26 kleber: the issuer doesn't have to be someone you're visiting right now 09:06:05 kleber: news.example could ask for trust-r-us.example to issue stuff just on the basis on news.example activity! 09:06:09 reillyg has joined #trusttokens 09:06:16 …so can be single-domain 09:06:31 …cross-domain usage like that would require cross-domain tracking 09:06:43 q+ 09:07:10 toml: You said "they need ot avoid linking you to the device"; that's not true...you just need to authenticate one time and you could potentially keep them around on the same or another device 09:07:25 …but maybe a credit-card company knows you real well 09:07:53 ack ian 09:08:08 Ian: so suppose i go to make a payment, the payment handler goes to an issuing bank and gets trust tokens, and that's better than the alternative 09:08:33 q? 09:08:37 ben: really thinking of payments without existing relationship 09:09:37 toml: I think that that use case is weird. The issuing bank would issue a credential. 09:09:47 ..and they would be worth money 09:09:54 mark: haven't read the proposal in a while 09:10:01 …so i'm browsing 09:10:02 rbyers has joined #trusttokens 09:10:11 …and sometimes i accumulate these tokens, just 'cause 09:10:24 …and sometimes i do other things, and have to spend those tokens 09:10:33 …can that site say which tokens they accept? 09:10:46 kleber: yes, can be multiple, can't be many 09:10:52 q+ to ask about issuer binding 09:11:01 mark: so the goal is for them to represent trust 09:11:08 …but they could represent something else 09:11:12 q? 09:11:25 kleber: behold the question: who can be an issuer? 09:11:41 …but if we allow anyone to issue them, maybe they're used for non-trust reasons? 09:11:45 …what even 09:11:53 …what restrictions do we need if we do that 09:12:11 mark: but when there's a privileged action, that sounds like consolidation of power 09:12:17 …v. interesting 09:12:31 kleber: yea, but i hope this sounds pretty benign 09:12:38 mark: IDK, you know 09:12:44 …could get weird 09:12:48 q? 09:12:50 kleber:yeah 09:12:59 tony: can they be shared between browsers? 09:13:08 kleber: expect them to be browser-specific 09:13:24 …not accessible to js apis or ~~~~extensions~~~ 09:13:45 ack btidor 09:13:49 mwest: possible to for browsers to share if they want, possibly syncing. 09:13:50 ack tom 09:13:50 toml, you wanted to ask about issuer binding 09:13:54 scribenick: Ian 09:14:07 rmondello has joined #trusttokens 09:14:09 toml: You mentioned (Michael) limiting a site to only accepting trust tokens from a couple of possible issuers 09:14:27 ...but that seems like it would trap a site in the dilemma of which 3 companies it might rely on. 09:14:51 ...I would suggest that it is innocuous to require a site to pick a small number of parties it is willing to rely on 09:15:00 Michael: It's a tradeoff 09:15:08 ...entropy leakage v. flexibility 09:15:26 Rossen_ has joined #trusttokens 09:15:32 toml: I am optimistic that there's an approach that can put a ceiling on the cross-site entropy by having some degree of negotiation between browsers and sites 09:15:39 q? 09:15:46 ...where browsers get to pick and may do things inconsistently (intentionally) 09:15:53 scribenick: toml 09:16:02 ???2: do tokens live forever? 09:16:14 kleber: only as long as those issuing keys are valid 09:16:22 …browsers could limit key lifetimes 09:16:30 …could be some lifetime for those things 09:16:39 …but evertokens seem fine too probably 09:17:05 …seems like fast rotation is also bad because revealing 09:17:08 ben: revocable? 09:17:10 q? 09:17:12 kleber: nope 09:17:30 kleber: so probably don't give out too many tokens 09:17:44 toml: I propose "fungible" instead of "indistinguishable" 09:17:53 michael: Sounds good 09:18:01 …but maybe that's why you rotate keys 09:18:18 kleber: what the browser knows is that the token is signed by a particular key 09:18:41 …or it could be signed by any of N keys! that's another neat trick! 09:18:41 toml: Might be compatible with older versions of blind sigs 09:19:09 …before, it was signed with a particular key, now it might only be signed with one of several keys 09:19:22 …so now you can issue trust and distrust too! 09:19:36 …some of those keys are for the good bit, some for the bad bit 09:19:58 …so you can secretly issue people bad tokens when they think they're getting good tokens 09:20:12 …good for preventing fraud by lengthening the cycle 09:20:35 ???2: but presumably the relying site is going to give the game away 09:20:50 kleber: no, redemption happens on the issuer site to get that cert 09:21:08 …but yes you're right, they might give the game away 09:21:21 …but maybe they pretend to do the right thing, but secretly don't 09:21:29 q? 09:21:45 john: can consume the tokens and claim legitimacy, but only the user is fooled 09:21:50 q+ 09:21:53 I have made the request to generate https://www.w3.org/2019/09/18-trusttokens-minutes.html Ian 09:22:04 kleber: relevance to conversion measurement 09:22:22 john: how to prevent fraud with non-identifying ad-click attribution 09:22:23 q+ to ask where you/the room would like to see this go next 09:22:45 …soooo, maybe we use trust tokens with the attribution reports to anti-sibyl? 09:23:00 …two tokens, one at click time, and one from the advertiser when you convert 09:23:15 …but only when the browser associates those events are those things used 09:23:44 kleber: yes, multipurpose! can be used for many situations where a server wants to send fungible messages to future self 09:23:53 …might not be a single bit, might not need to be hidden 09:24:05 …might just want to report a conversion of type seventeen 09:24:14 …token wrapped around 17, blind sig on 17 09:24:26 …then those private tokens can be passed around like this 09:24:45 john: that would make all these advertisers and so on issuers of tokens 09:25:26 I have made the request to generate https://www.w3.org/2019/09/18-trusttokens-minutes.html Ian 09:25:28 ack wsl 09:25:30 …one more thing: because of how it's specced for 24-48h delay before reports, proofs can be lazily checked to help prevent sneaky iding 09:25:31 ack ws 09:25:31 wseltzer, you wanted to ask where you/the room would like to see this go next 09:25:46 wendy: where do you and the room see this going next? 09:26:05 kleber: for me, personally, most interested in the ad fraud use case as cookies stop being good for that 09:26:09 …but clearly lots of them 09:26:15 …just came up with another use case 09:26:32 …works with microsoft's auditability spec 09:26:44 (Soft proposal: WICG) 09:26:46 ???3: so wicg? 09:27:06 ???4: does someone else want this? 09:27:14 kleber: cloudflare, for sure 09:27:17 s/???3/blassey 09:27:18 john: apple too 09:27:30 s/???4/rickbyers/ 09:27:42 toml: I am not sure WICG is the right venue 09:28:04 wseltzer: WICG can be a place for collaborative development and is designed for that 09:28:09 wendy: wicg could support collaborative development! 09:28:32 …if there's a pattern of non-collaborative development, that shouldn't reflect the norm 09:28:50 toml: Could be in the privacy CG 09:29:02 kleber: seems like wicg is right 09:29:45 toml: My impression of the decision-making mechanic is wicg is that there's one author who writes the spec; that may not be a dynamic that solicits a lot of input 09:30:13 toml: "Trust tokens, very exciting, lots of applications, ready for more work in group TBD!" 09:30:21 I have made the request to generate https://www.w3.org/2019/09/18-trusttokens-minutes.html Ian 09:33:21 MasayaIk_ has joined #trusttokens 10:06:29 MasayaIkeo has joined #trusttokens 12:01:18 dave has joined #trusttokens 13:19:07 Zakim has left #trusttokens 13:35:56 Ian has left #trusttokens