IRC log of trusttokens on 2019-09-18

Timestamps are in UTC.

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