Trust Tokens

18 Sep 2019


toml, kleber, Ian
Michael Kleber
toml, Ian


<Ian> Scribenick: toml

<scribe> scribenick: toml

kleber: Trust Tokens are an API from Chrome's Privacy Sandbox
... : history: build on Cloudflare's Privacy Pass

<Ian> Trust Token Explainer

kleber: : want to extend to new uses in this privacy world
... : goal is to help prevent fraud & abuse
... : today, this involves detecting patterns of malicious behavior
... : if you can't recognize people, that ability vanishes
... : this is an attempt to retain some spam/fraud-fighting capabilities while also removing identification/tracking
... : core tech: blinded tokens which are crypto magic
... : an issuer mints tokens signed with a cryptographic key in a ritual between browser and issuer

<Ian> toml: Did you mean "indistinguishable from any token signed with the same key"

<Ian> ...I think they are distinguishable from one another, but you can't tell which one was emitted with a given issuing event

<Ian> toml: They are distinguishable, but not correlatable (across different sites)

kleber: : tokens are cryptographically guaranteed to have been issued by the issuer, but each token
... tokens are unique, but the issuer doesn't know which tokens it's issued, only how many it's issued and redeemed

[some clarification of token primitive]

kleber: tokens represent one bit of information: "at some point in the past you trusted me"

<Ian> (Ian likes "a message to its future self" :)

kleber: : way for issuer to send a message to self in future, and message is "you trust this person"
... : ex banks might issue tokens to their legit customers
... : or Google might give them to longtime search users
... : original use case was to represent having completed a CAPTCHA for anonymous user (via Tor)
... : 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
... : fine when there's one issuer
... : want this to be a web standard where many people can issue tokens in different cases, and no need to use an extension
... : needs some limits, imagine 100 issuers — which of those you're holding tokens from might constitute an ID
... : so some limit on how many issuers you can be asked to pend tokens from on the same site

tony: is this using any hardware based stuff for key storage

kleber: all important crypto is server side

tony: platform crypto?

kleber: yes
... : some browser crypto needed to verify the ZKP non-uniqueness key

tony: so what does it use today?

kleber: platform crypto rn. no in-browser/js impl. no webcrypto RN, who knows the future.
... second capability for our use case: ads!
... : we want to avoid ads fraud
... : next slide please
... : ad companies work hard to fight fraud
... : want to keep doing that without 3p cookies
... : 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
... : present token back to google as verifier, google passes back certificate indicating trust from google on NYtimes
... : then you have a persistent gesture of trust
... : persistant keypair used for this session transaction

tony: not bound to http session?

kleber: no, more like cookies?

+q to ask about certs

tony: how scoped?

kleber: haven't decided yet
... : probably origin tho? IDK? just use more tokens on more domains.

<Ian> scribenick: Ian

toml: I want to review the transaction flow you outlined.
... I'm a browser; google issues trust tokens to me; I have them in the browser and visit news.example.
... they say "I want a trust token; we accept providers, A, B, and Google"
... the browser gives a trust token and then google verifies?

Michael: Plausible but we were thinking of a different flow
... browser asks news.example with a cert

toml: So when presented with a challenge from the news site, the browser does a redemption operation on the issuer site

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

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"
... and when the user agent decides it's time to clear state,
... 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

<scribe> scribenick: Toml

kleber: looking for feedback here
... : deanon risk exists even though it's 1 bit at a time
... the sort of attacks are exactly the ones you'd expect
... 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
... so you need to box the idp selection per site: can't change providers very often
... maybe if they change idps, you need to clear info about that site to avoid leakage
... 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
... 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

???: so the issuer could use certain keys per ip?

kleber: recognizing the user lets them do that

???2: another attack surface — potentially revealing which IDPs you rely on

kleber: if you're not affiliated with the idps that a site trusts, then maybe you get a bunch of challenges
... seems unlikely

tony: is there crypto agility in this?

Brad_Lassey: the voprf spec is an individual draft submitted in the IETF
... not adopted yet

tony: pointer to the internet draft?

<Ian> s/???3/Brad_Lassey/g

toml: there are also way old implementations of blind tokens with no ip implications imo

ack toml;

<Zakim> toml, you wanted to ask about certs

<blassey> https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/

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?

kleber: probs not, tbh
... the issuer doesn't have to be someone you're visiting right now
... news.example could ask for trust-r-us.example to issue stuff just on the basis on news.example activity!
... so can be single-domain
... cross-domain usage like that would require cross-domain tracking

<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

kleber: but maybe a credit-card company knows you real well

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

ben: really thinking of payments without existing relationship

<Ian> toml: I think that that use case is weird. The issuing bank would issue a credential.

<Ian> ..and they would be worth money

mark: haven't read the proposal in a while
... so i'm browsing
... and sometimes i accumulate these tokens, just 'cause
... and sometimes i do other things, and have to spend those tokens
... can that site say which tokens they accept?

kleber: yes, can be multiple, can't be many

mark: so the goal is for them to represent trust
... but they could represent something else

kleber: behold the question: who can be an issuer?
... but if we allow anyone to issue them, maybe they're used for non-trust reasons?
... what even
... what restrictions do we need if we do that

mark: but when there's a privileged action, that sounds like consolidation of power
... v. interesting

kleber: yea, but i hope this sounds pretty benign

mark: IDK, you know
... could get weird

kleber: yeah

tony: can they be shared between browsers?

kleber: expect them to be browser-specific
... not accessible to js apis or ~~~~extensions~~~

mwest: possible to for browsers to share if they want, possibly syncing.

<Zakim> toml, you wanted to ask about issuer binding

<Ian> scribenick: Ian

toml: You mentioned (Michael) limiting a site to only accepting trust tokens from a couple of possible issuers
... but that seems like it would trap a site in the dilemma of which 3 companies it might rely on.
... I would suggest that it is innocuous to require a site to pick a small number of parties it is willing to rely on

Michael: It's a tradeoff
... entropy leakage v. flexibility

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
... where browsers get to pick and may do things inconsistently (intentionally)

<toml> scribenick: toml

???2: do tokens live forever?

kleber: only as long as those issuing keys are valid
... browsers could limit key lifetimes
... could be some lifetime for those things
... but evertokens seem fine too probably
... seems like fast rotation is also bad because revealing

ben: revocable?

kleber: nope
... so probably don't give out too many tokens

<Ian> toml: I propose "fungible" instead of "indistinguishable"

<Ian> michael: Sounds good

kleber: but maybe that's why you rotate keys
... what the browser knows is that the token is signed by a particular key
... or it could be signed by any of N keys! that's another neat trick!

<Ian> toml: Might be compatible with older versions of blind sigs

kleber: before, it was signed with a particular key, now it might only be signed with one of several keys
... so now you can issue trust and distrust too!
... some of those keys are for the good bit, some for the bad bit
... so you can secretly issue people bad tokens when they think they're getting good tokens
... good for preventing fraud by lengthening the cycle

???2: but presumably the relying site is going to give the game away

kleber: no, redemption happens on the issuer site to get that cert
... but yes you're right, they might give the game away
... but maybe they pretend to do the right thing, but secretly don't

john: can consume the tokens and claim legitimacy, but only the user is fooled

kleber: relevance to conversion measurement

john: how to prevent fraud with non-identifying ad-click attribution
... soooo, maybe we use trust tokens with the attribution reports to anti-sibyl?
... two tokens, one at click time, and one from the advertiser when you convert
... but only when the browser associates those events are those things used

kleber: yes, multipurpose! can be used for many situations where a server wants to send fungible messages to future self
... might not be a single bit, might not need to be hidden
... might just want to report a conversion of type seventeen
... token wrapped around 17, blind sig on 17
... then those private tokens can be passed around like this

john: that would make all these advertisers and so on issuers of tokens
... 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

<Zakim> wseltzer, you wanted to ask where you/the room would like to see this go next

wendy: where do you and the room see this going next?

kleber: for me, personally, most interested in the ad fraud use case as cookies stop being good for that
... but clearly lots of them
... just came up with another use case
... works with microsoft's auditability spec

<Ian> (Soft proposal: WICG)

blassey: so wicg?

rickbyers: does someone else want this?

kleber: cloudflare, for sure

john: apple too

<Ian> toml: I am not sure WICG is the right venue

<Ian> wseltzer: WICG can be a place for collaborative development and is designed for that

wendy: wicg could support collaborative development!
... if there's a pattern of non-collaborative development, that shouldn't reflect the norm

<Ian> toml: Could be in the privacy CG

kleber: seems like wicg is right

<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

<Ian> toml: "Trust tokens, very exciting, lots of applications, ready for more work in group TBD!"

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/18 09:30:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/???3/Brad_Lassey/
FAILED: s/???3/Brad_Lassey/g
Succeeded: s/???3/blassey/
Succeeded: s/???4/rickbyers/
Present: toml kleber Ian
Found ScribeNick: toml
Found ScribeNick: toml
Found ScribeNick: Ian
Found ScribeNick: Toml
Found ScribeNick: Ian
Found ScribeNick: toml
Inferring Scribes: toml, Ian
Scribes: toml, Ian
ScribeNicks: toml, Ian

WARNING: No "Topic:" lines found.

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]