[01:06:06] Ben Schwartz (chair) joins the room
[01:34:51] Godfred joins the room
[01:35:57] Godfred leaves the room
[01:36:55] Ben Schwartz (chair) leaves the room
[10:01:05] wilma joins the room
[10:01:21] wilma leaves the room
[10:01:59] wilma joins the room
[10:02:06] wilma leaves the room
[19:05:23] Ben Schwartz (chair) joins the room
[19:22:08] alxdavids joins the room
[19:22:19] alxdavids leaves the room
[19:22:36] alxdavids joins the room
[19:22:54] alxdavids leaves the room
[19:23:02] alxdavids joins the room
[19:30:41] jbui joins the room
[19:30:57] svaldez joins the room
[19:30:57] svaldez leaves the room
[19:31:04] svaldez joins the room
[19:31:04] svaldez leaves the room
[19:31:10] dvorak42@mit.edu/barnowl joins the room
[19:31:10] dvorak42@mit.edu/barnowl leaves the room
[19:31:13] dvorak42@mit.edu/barnowl joins the room
[19:31:13] dvorak42@mit.edu/barnowl leaves the room
[19:32:20] svaldez joins the room
[19:32:57] svaldez2 joins the room
[19:33:04] svaldez2 leaves the room
[19:33:52] svaldez leaves the room
[19:34:34] svaldez@jabb.im/barnowl joins the room
[19:34:45] svaldez@jabb.im/barnowl is now known as svaldez
[19:35:24] svaldez is now known as svaldez@jabb.im/barnowl
[19:35:45] svaldez@jabb.im/barnowl leaves the room: Connection failed: connection closed
[19:36:11] svaldez@jabb.im/barnowl joins the room
[19:36:25] Nick Sullivan joins the room
[19:37:15] svaldez@jabb.im/barnowl is now known as svaldez
[19:37:28] armfazh joins the room
[19:43:12] ash joins the room
[19:47:00] jhoyla joins the room
[19:47:46] Barry Leiba joins the room
[19:47:49] pardue joins the room
[19:48:10] Olaf Kolkman joins the room
[19:48:27] joesal1@jabber.hot-chilli.net joins the room
[19:48:30] watson17 joins the room
[19:49:01] Bob Moskowitz joins the room
[19:49:06] watson17 leaves the room
[19:49:35] hardie joins the room
[19:49:42] jimsch1 joins the room
[19:50:31] <Bob Moskowitz> Got my cookies (Oreos!) and my cup of tea (Kenyan this time)
[19:50:53] xp29srs joins the room
[19:51:24] sftcd joins the room
[19:51:25] Sofia Celi joins the room
[19:52:03] drazen joins the room
[19:52:26] Cathy Aronson joins the room
[19:53:09] martin.duke joins the room
[19:53:44] <Barry Leiba> Kenyan is nice.
[19:53:59] Pete Resnick joins the room
[19:54:04] <Barry Leiba> I need to find a nice lapsong souchong, as I've run out.
[19:54:08] svaldez leaves the room: Connection failed: connection closed
[19:54:10] svaldez joins the room
[19:54:12] <Bob Moskowitz> It is a smooth variant of the more common Celyon teas.
[19:54:43] sfuerst joins the room
[19:54:50] adam joins the room
[19:55:09] <Bob Moskowitz> TWG has a nice one.  They have stores in the US to order from.  Twinings is great, but it ships from the UK.  Their tea bags, locally are OK.
[19:55:22] Jim Fenton joins the room
[19:55:41] Yoshiro YONEYA joins the room
[19:55:42] Dan York joins the room
[19:55:47] Tommy Pauly joins the room
[19:55:56] Alissa Cooper joins the room
[19:56:50] Cindy Morgan joins the room
[19:56:50] dkg joins the room
[19:57:18] watson17 joins the room
[19:57:29] Dave Thaler joins the room
[19:57:33] watson17 leaves the room
[19:57:37] Eric Vyncke joins the room
[19:57:39] mbaushke@jabber.hot-chilli.net joins the room
[19:57:51] mbaushke@jabber.hot-chilli.net leaves the room
[19:58:10] Mark Baushke (Juniper) joins the room
[19:58:33] johnk joins the room
[19:58:40] csperkins joins the room
[19:58:57] Alexey Melnikov joins the room
[19:58:58] oneeyedian joins the room
[19:59:05] chi.jiun.su joins the room
[19:59:18] Warren Kumari joins the room
[20:00:12] <jhoyla> Phew, my sound _is_ working.
[20:00:13] npdoty@xmpp.jp joins the room
[20:00:18] kaduk@jabber.org/barnowl joins the room
[20:00:25] npdoty@xmpp.jp leaves the room
[20:00:29] Tommy Pauly leaves the room
[20:00:41] joehall joins the room
[20:00:51] Rich Salz joins the room
[20:00:52] mnot joins the room
[20:00:52] m&m joins the room
[20:00:55] wilma joins the room
[20:01:00] SM joins the room
[20:01:13] Melinda joins the room
[20:01:31] Greg Wood joins the room
[20:01:32] Martin Thomson joins the room
[20:01:39] kaduk@jabber.org/barnowl leaves the room
[20:01:48] Ben Campbell joins the room
[20:01:53] <Dan York> I can relay from Jabber if necessary.
[20:01:54] <Ben Schwartz (chair)> https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass
[20:01:59] Karen O'Donoghue joins the room
[20:02:07] kaduk@jabber.org/barnowl joins the room
[20:02:09] cabo joins the room
[20:02:10] <svaldez> Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass
[20:02:15] Stefan Santesson joins the room
[20:02:17] Amelia Andersdotter joins the room
[20:02:23] Samuel Weiler joins the room
[20:02:24] <svaldez> https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass
[20:02:35] whatdafuq joins the room
[20:02:47] Shumon Huque joins the room
[20:02:53] <dkg> cheers on the HTML agenda, with actual links!  it's like we're living in the 1990s instead of the 1980s!
[20:02:57] Cullen Jennings joins the room
[20:03:05] Jari Arkko joins the room
[20:03:16] <Martin Thomson> datatracker isn't showing HTML for me
[20:03:24] <dkg> https://datatracker.ietf.org/meeting/107/materials/agenda-107-privacypass
[20:03:25] amontville joins the room
[20:03:58] svaldez2 joins the room
[20:03:58] svaldez2 is now known as dvorak42@mit.edu/barnowl
[20:03:59] dvorak42@mit.edu/barnowl leaves the room
[20:04:01] <kaduk@jabber.org/barnowl> dkg: what would it take to move to the 21st century?
[20:04:01] <Martin Thomson> Oh, so the markdown conversion is partially working: https://datatracker.ietf.org/meeting/107/materials/agenda-107-privacypass-04
[20:04:08] Steven Valdez joins the room
[20:04:11] Dirk Balfanz joins the room
[20:04:15] <dkg> kaduk@jabber.org/barnowl: let's not get ahead of ourselves
[20:04:39] ysakemin joins the room
[20:04:40] <jhoyla> Embedded exploits?
[20:04:47] sftcd likes 1990's style web pages
[20:04:50] stevenvaldez joins the room
[20:04:50] stevenvaldez leaves the room
[20:05:25] bhoeneis joins the room
[20:05:29] Wes Hardaker joins the room
[20:06:00] StephenBotzko joins the room
[20:06:03] watson17 joins the room
[20:06:13] Steven Valdez leaves the room
[20:06:29] g.e.montenegro joins the room
[20:06:40] svaldez2 joins the room
[20:06:40] svaldez2 leaves the room
[20:06:45] synp joins the room
[20:06:58] Jari Arkko leaves the room
[20:07:00] Jari Arkko joins the room
[20:07:20] tfpauly joins the room
[20:07:35] Andrew Campling joins the room
[20:07:37] brandon.maslen joins the room
[20:07:59] <svaldez> https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-use-cases
[20:08:01] synp joins the room
[20:08:11] Jonathan Hoyland joins the room
[20:08:29] <sftcd> trust attestation isn't a great term IMO but whatever
[20:08:36] <dkg> slide 3
[20:09:06] <dkg> slide 4
[20:09:09] <Samuel Weiler> slides not appearing, using webrtc client
[20:09:25] <dkg> Samuel Weiler: i can see them using chromium
[20:09:28] <kaduk@jabber.org/barnowl> The slides appear here; try loading again in a different tab?
[20:09:30] Valery Smyslov joins the room
[20:09:32] <Ben Schwartz (chair)> I can see them in Firefox
[20:09:34] <cabo> Slides do appear, using webrtc client on Chrome
[20:09:35] <sftcd> @sam: working for me also chromium
[20:09:36] <Eric Vyncke> @Sam refresh canhelp
[20:09:41] carrickdb@jabber.calyxinstitute.org joins the room
[20:09:57] <dkg> slide 5
[20:09:58] <kaduk@jabber.org/barnowl> In other sessions we've had issues with the video stream dropping when
switching who is presenting, but since this is still Joe's screen I'm
not sure that applies
[20:10:20] <dkg> sftcd: i agree that "trust attestation" is problematic
[20:10:21] svaldez leaves the room
[20:10:28] svaldez joins the room
[20:10:32] <dkg> slide 6
[20:10:37] <Ben Campbell> It's coming through fine with the mac client (not webRTC)
[20:11:08] mglt joins the room
[20:11:20] <Jim Fenton> So I guess this keeps the mechanical turn bill lower to prove that your bot is human?
[20:11:25] <sftcd> privacy preserving cookie maybe? but not sure of all their use cases
[20:11:25] <Jim Fenton> *turk
[20:11:40] Adam W. / Stu C. joins the room
[20:11:41] Nick Doty joins the room
[20:11:51] <dkg> slide 7
[20:12:07] Peter Wu joins the room
[20:12:20] Cullen Jennings leaves the room: Replaced by new connection
[20:12:21] Cullen Jennings joins the room
[20:12:27] <dkg> slide 8
[20:12:27] Cullen Jennings leaves the room
[20:12:51] <dkg> slide 9
[20:13:31] <dkg> slide 10
[20:13:51] ssahib joins the room
[20:14:10] <dkg> slide 11
[20:14:33] <Nick Doty> "across origins" has been mentioned a couple times, but the diagrams just show 1 server. is there also server to server communication so that a Web server can pass along a token from one of its users?
[20:15:08] <Jim Fenton> My question too, diagrams just show 1:1 interaction
[20:15:10] <Martin Thomson> I'm not sure that these numbers are relevant here.
[20:15:17] <dkg> we're also talking to a cloudflare person, so they are maybe thinking about one server that serves several hosts
[20:15:22] petereyee joins the room
[20:15:26] watson17 leaves the room
[20:15:28] <dkg> slide 12
[20:15:28] tfpauly leaves the room
[20:16:18] <kaduk@jabber.org/barnowl> it's public-key crypto; some (but not all) schemes here allow
"offline" validation just by knowing the issuer's public key.
[20:16:28] <Nick Sullivan> @nickdoty the architecture document goes into the one-to-one, many-to-one, and many-to-many scenarios
[20:17:38] ekinnear joins the room
[20:17:43] <dkg> slide 13
[20:17:43] <pardue> https://tools.ietf.org/html/draft-davidson-pp-architecture-00
[20:17:44] tfpauly joins the room
[20:17:53] <Nick Doty> Nick Sullivan: I promise that I did look quickly at the architecture document, but didn't immediately understand
[20:18:09] tancrede joins the room
[20:18:39] <Nick Sullivan> The server in this case can be one gateway in front of multiple origins, or independent servers
[20:19:20] <cabo> Should I say "ouch" each time he says "trust-based attestation"?
[20:19:34] <dkg> i think we should say what terms we prefer ☺
[20:19:46] <dkg> end of deck
[20:19:50] <cabo> (Actually, it's ouch-ouch — one for "trust" and one for "attestation"
[20:19:51] <sftcd> anyone know which of these use-cases involves interop where the servers involved are really independent entities?
[20:20:17] <cabo> Yes, please be more clear about the players
[20:20:53] Roman Danyliw joins the room
[20:21:18] <Bob Moskowitz> I was also thinking about RATS as I saw this.
[20:21:30] <sftcd> so "internet setting" == "web" eh? :-)
[20:21:40] <Pete Resnick> It makes me sad that RATS was not forward in mind.
[20:21:42] <Martin Thomson> My understanding is that RATS doesn't have this unlinkable requirement
[20:21:42] <Mark Baushke (Juniper)> IETF RATS did indeed directly come to mind.
[20:21:49] <synp> It's been like that for 25 years, Stephen
[20:22:15] spencerdawkins joins the room
[20:22:58] g.e.montenegro leaves the room
[20:23:10] <Pete Resnick> @mt: Is that an additional requirement RATS, or a just limiting (subcase) requirement?
[20:23:23] <Pete Resnick> s/RATS/on RATS
[20:23:47] <Martin Thomson> this is complementary to the RATS work: RATS describes how the client might generate an attestation, this describes how that attestation might be taken to someone else
[20:24:01] <Pete Resnick> ack
[20:24:02] Satoru Kanno joins the room
[20:24:04] <hardie> Does this imply that they are also replayable, if different clients present them to different servers?
[20:24:17] <Ben Schwartz (chair)> hardie: No, they are single-use
[20:24:28] <Wes Hardaker> it to me imlpies they're stealable too.
[20:24:30] <hardie> @Ben Does that rely on back-end coordination?
[20:24:32] <kaduk@jabber.org/barnowl> the "different servers" would have to coordinate to enforce the
single-use property globally
[20:24:37] <Martin Thomson> single-use is a necessary part of this
[20:24:38] <Ben Schwartz (chair)> hardie: Yes, unified backend
[20:24:44] <Wes Hardaker> (from an unlocked wallet at least)
[20:24:50] <hardie> @Ben  Thanks for the clarification.
[20:24:55] <Ben Campbell> is sound breaking up for others?
[20:24:58] <adam> I mean, once you have prove-once-use-many, then things like Selenium allow for automation, and there's never going to be a way around that.
[20:25:03] <Wes Hardaker> @ben: no
[20:25:05] <dkg> linking tokens to an identity seems like it is in opposition to the initial goal
[20:25:09] <Bob Moskowitz> If these tokens are transferable between clients, then they can be printed at say a bar as QR codes and passed around...
[20:25:11] <adam> Ben Campbell: Sounds good here
[20:25:21] <kaduk@jabber.org/barnowl> Ben C: Brendan's audio was not great but others' have been okay
[20:25:59] merm joins the room
[20:26:06] <svaldez> Its also the case that different things built on top of this might
answer the transferability question in different ways.
In the web case, tokens might be treated in a similar way to cookies,
in that they are technically transferable (not bound to a specific
client), but not trivial to move between users.
[20:26:19] <Dave Thaler> @Martin: RATS doesn't have unlinkability as a core requirement, but you can add that requirement into any particular solution
[20:26:20] ekinnear leaves the room
[20:26:24] <Jonathan Hoyland> It's a like an injective Aliveness property. "There was at one point a human", rather than a strong authentication property "I am a human".
[20:26:32] Christian Huitema joins the room
[20:26:39] merm leaves the room
[20:26:58] <Nick Doty> "there was at one point a human" is pretty often what we get from CAPTCHAs now
[20:27:00] ekinnear joins the room
[20:27:13] <kaduk@jabber.org/barnowl> which people seem to think is still useful!
[20:27:15] g.e.montenegro joins the room
[20:27:26] jon-ietf joins the room
[20:28:05] watson17 joins the room
[20:28:08] <Jonathan Hoyland> "There was at one unique point a human" actually, i.e. tokens can't be reused.
[20:28:09] <sftcd> so have any of the proponents considered if there are abuse cases? i.e. ways in which this tech could be used against users
[20:29:28] <synp> So it's a unified backend, meaning that Daniel's scenario doesn't work. You can't use a token from Cloudflare for Facebook.  It's not indpendent servers, but linked servers
[20:29:29] sofia joins the room
[20:29:29] <Dave Thaler> I am not convinced it's fair to actually use the word "attestation" for this "there was at one point a human" which is not about "I" or "now" or anything else specific
[20:29:33] <dkg> the multiple consumer use case also has worse anti-replay properties
[20:29:43] <Jonathan Hoyland> There is some consideration of malicious servers in the architecture document.
[20:29:45] tfpauly leaves the room
[20:30:24] <synp> @sftcd: I can get some malware in your browser to have you get tokens which I can harvest.  That's one abuse case
[20:30:30] <Nick Doty> if there are too many issuers, then which issuer the user uses could become identifying
[20:30:34] <Jonathan Hoyland> @Dave Thaler Can you not attest to any fact?
[20:31:02] <kaduk@jabber.org/barnowl> Nick: IIRC that's also mentioned in the architecture
[20:31:18] <Jim Fenton> Trying to understand the privacy issue if Cloudflare is both issuer and consumer of these tokens.
[20:31:37] <kaduk@jabber.org/barnowl> Jim: the "unlinkable" property is supposed to get around that
[20:31:39] tfpauly joins the room
[20:31:50] leifj joins the room
[20:31:54] <dkg> https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-ecosystem
[20:31:58] <kaduk@jabber.org/barnowl> *waves the crypto magic wand*
[20:32:01] <synp> Is it fair to say that it's Cloudflare keeping your identity private from their own customers?
[20:32:01] <dkg> slide 3
[20:32:03] <Jonathan Hoyland> I think the key worry is CF shouldn't be able to tell which set of sites you visit from the tokes.
[20:32:03] <tancrede> Consumption is happening at a difference time from issuance, and we don't want to link both events
[20:32:15] <Jim Fenton> @kaduk But if same party is both issuer and consumer, what privacy issue needs to be solved?
[20:32:17] <dkg> slide 4
[20:32:53] <Jonathan Hoyland> I.e. CF knows that a person visited website A, and that a person visited website B, but should not be able to derive if both sites were visited by the same person.
[20:32:54] mglt leaves the room
[20:33:00] <Jim Fenton> I guess I don't understand how CDNs work well enough :/
[20:33:03] <Dave Thaler> @Jonathan you can claim anything you want, and so in the layman dictionary sense yes to your question.  But attestation in many standards contexts (in RATS, TCG, etc.) means something stronger for which transferability (as Brendan explained) is prevented
[20:33:13] mglt joins the room
[20:33:25] <sftcd> @jonathon: so the client has to get a new IP address to see benefit?
[20:33:27] <Nick Doty> kaduk, yes, I now see that specific privacy issue of many issuers in the architecture document. thanks
[20:33:28] <Andrew Campling> Dont forget taht CF might also be your DNS provider
[20:33:34] <Andrew Campling> that
[20:34:06] <Jonathan Hoyland> @sftcd I think the initial use case was TOR, so many users coming from a single IP address (i.e. an exit node)
[20:34:08] <Martin Thomson> I don't see any way to avoid clients having allowlists of token issuers.  Redeeming entities would necessarily have the same.
[20:34:08] wseltzer joins the room
[20:34:40] <dkg> Jonathan Hoyland: and tor also has the case where subsequent circuits come from different IP addresses
[20:34:50] <kaduk@jabber.org/barnowl> MT: I agree
[20:34:56] <dkg> sftcd: so yes, there is also benefit when IP addresses change
[20:35:17] <sftcd> @jonathan (sorry for name typo earlier:-) - this as a method for not requiring captcha for tor users is a good thing, sure
[20:35:35] <dkg> slide 5
[20:35:57] <dkg> slide 7
[20:35:59] <sftcd> ben is assuming we've read the drafts eh? :-)
[20:36:20] <Ben Schwartz (chair)> Or that you want to ask questions about them because you haven't!
[20:36:23] <kaduk@jabber.org/barnowl> This ben read the drafts; that's a transferrable property, right? ;)
[20:36:24] <Nick Doty> the architecture draft suggests only 4 or maybe 8 issuers total globally
[20:36:35] <leifj> how are you still the same issuer if you drop your key on the floor?
[20:36:36] Eric Kinnear joins the room
[20:37:20] <Martin Thomson> The best design I can arrive at has each relying party indicate precisely ONE issuer.  Just like an issuer needs to have transparency for their keys, the relying party needs to have transparency for their choice of issuer.
[20:37:20] <kaduk@jabber.org/barnowl> leifj: you can use the same TLS cert to authenticate your "generate
token" endpoint even if the token itself is generated with a new key
[20:37:40] carrickdb@jabber.hot-chilli.net joins the room
[20:37:50] carrickdb@jabber.calyxinstitute.org leaves the room: Disconnected: closed
[20:38:09] <leifj> ok then your trust root your TLS chain... but if you actually loose your key should your users still trust you?
[20:38:19] <dkg> slide 10
[20:38:52] <dkg> someone say "blockchain"
[20:38:58] <leifj> drink
[20:39:16] <Nick Doty> mt: that sounds annoying for the user, or leading to consolidation all to Cloudflare
[20:39:16] ekinnear leaves the room
[20:39:57] <leifj> its roots of trust all the way down
[20:39:57] Eric Kinnear leaves the room
[20:39:59] <dkg> Alex is conflating "issuer" with "consumer"
[20:40:04] <Jonathan Hoyland> @Nick Doty
[20:40:06] <dkg> (slide 11)
[20:40:09] ekinnear joins the room
[20:40:13] <Jonathan Hoyland> I wonder if you could do something with federation
[20:40:25] Cullen Jennings joins the room
[20:40:51] <leifj> federation doesn't get you trust it just allows you to glue together islands of trust (at best)
[20:41:05] Cullen Jennings leaves the room
[20:41:05] <dkg> slide 12
[20:41:11] <synp> The presentation has run to operational considerations, but here we're still debating the use cases.
[20:41:18] <Jonathan Hoyland> Hmm, federation across authenticated trees of issuers maybe?
[20:41:31] <dkg> slide 13
[20:41:34] <leifj> sure - that may overcome some scaling issues
[20:41:35] <sftcd> has there been any interop between those implementations?
[20:41:37] <synp> Are we expecting to be able to hum on charter by the end of this session?
[20:41:39] <Dave Thaler> I think it was answered earlier, but in their proposal, can the same token be reused multiple times or just one-time?  (just one-time I think, yes?)
[20:41:51] <adam> leifj: So, the example of CAPTCHA shows that, e.g., various sites already trust Google to vouch for their human test. So for certain kinds of assertions, doesn't this make sense?
[20:42:03] <alxdavids> @Dave yes they're only intended to be used one time
[20:42:03] tfpauly leaves the room
[20:42:18] <leifj> @adam yes it does - I'm wondering how much complexity that usecase is "worth"
[20:42:26] <adam> Like, wouldn't it make sense for a site to accept an "is a human" token from Google OR Facebook OR Cloudflare?
[20:42:36] <alxdavids> @sftcd There isn't currently any interop between these implementations
[20:42:37] <Nick Doty> Dave: that's the discussion of double spending and eventual consistency
[20:42:39] tfpauly joins the room
[20:42:54] <adam> I think the value lies in not having excessive pressure to vertical integration
[20:43:02] <Dave Thaler> why is it a problem, vs a timeout of some sort?  what problem is one-time solving?
[20:43:12] <adam> Like, honestly, if this is being done in limited trust scopes, it seems that standardization has pretty limited value.
[20:43:12] <dkg> i agree with subodh that there are definitely applications where double-spend isn't as important
[20:43:13] <leifj> otoh if we're extending the usecase to carrying around assertions that is worth more than "human"... we definitely need federation because the issuers *need* to be more diverse than google
[20:43:17] tfpauly leaves the room
[20:43:30] <sftcd> @alxdavids: is there a need for interop between those implementations? (not being negative just trying to understand the desire for a standard)
[20:43:39] <leifj> @adam exactly my point
[20:43:42] <Christian Huitema> The double spending part reminds me of David Chaum's DigiCash.
[20:43:42] Cathy Aronson leaves the room
[20:43:44] <adam> sftcd +1
[20:44:12] <Ben Schwartz (chair)> Christian Huitema: The crypto is a followup to Chaum's blind signature scheme.  It's similar but much more efficient.
[20:44:14] <leifj> @christian this was presented in saag a couple of meetings back and digicash was mentioned as inspiration
[20:44:21] <Jonathan Hoyland> Can we reuse some of the work from TLS 0-RTT w.r.t. double-spend protection?
[20:44:35] <kaduk@jabber.org/barnowl> Jonathan: yes
[20:44:37] <leifj> however one problem is that digicash can be validated offline
[20:44:42] <Dave Thaler> why is double-spend a problem?
[20:44:44] <leifj> privacypass can't
[20:45:02] <kaduk@jabber.org/barnowl> double-spend is not always bad, but 10,000-spend is bad
[20:45:07] <leifj> @davethaler - think about proving you're a student
[20:45:12] <Dave Thaler> why?
[20:45:20] <Christian Huitema> @Ben Schwartz so you need to rely on some kind of "issuer bank" to detect double spending?
[20:45:24] <leifj> you only want that to be possible for a limited number of times
[20:45:24] <Martin Thomson> kaduk@jabber.org/barnowl: that's the TLS 1.3 0-RTT anti-replay stance
[20:45:30] <Dave Thaler> I get having an expiration but not why the amount within that time matters
[20:45:32] <sftcd> 10000-spend - if someone has that many data centres then I have a hard time having sympathy for 'em :-)
[20:45:32] <leifj> or you'll get your discounts for ever
[20:45:42] <alxdavids> @sftcd: Currently the only reason is that they do not interop is because the crypto doesn't exactly match up. The intention to standardise to describe and analyse the privacy impact of cultivating an ecosystem around all the client and servers that participate.
[20:45:43] <Ben Schwartz (chair)> Christian Huitema: Yes, that's the "redeemer".
[20:45:45] <carrickdb@jabber.hot-chilli.net> Richard: isn't the point that a malicious server would seem to be doing the protocol, but in fact not be?
[20:45:48] xp29srs leaves the room
[20:46:22] <Nick Doty> because I could solve the captcha once and give it to a million of my boys?
[20:46:28] <Jonathan Hoyland> DDoS prevention
[20:46:28] <Nick Doty> bots, rather
[20:46:36] <carrickdb@jabber.hot-chilli.net> @Nick bois
[20:47:30] watson17 leaves the room
[20:47:34] <Martin Thomson> Dave Thaler: because one client making 10 attempts and 1000000 clients making 1 attempt is not distinguishable to the issuer/relier
[20:47:34] <leifj> @davethaler - I proove that I am a student for this one trainticket
[20:47:45] <Nick Doty> it's nice to the web browsing user if they can solve a captcha and be considered human for a fairly long period of time
[20:47:50] g.e.montenegro leaves the room
[20:48:02] watson17 joins the room
[20:48:19] <Christian Huitema> Actually the similarity with DigiCash has interesting privacy properties. If N users don't trace the issuer, they can pool, shuffle and redistribute their tokens.
[20:48:27] Cathy Aronson joins the room
[20:49:30] <Jonathan Hoyland> If you only issue tokens on Captcha solve, one token issued per session would be excruciating.
[20:49:38] Cathy Aronson leaves the room
[20:49:39] <hardie> @Christian  How would you distinguish valid tokens from invalid?  Isn't there a risk that you give a good token and get a "lug" in return?
[20:50:55] <Dave Thaler> @Martin,leif: yes I understand it's a workaround for not having a solution that prevents transferability.  If oyu could get non-transferability and unlinkability in the same solutin, then you would not need one-time tokens.
[20:50:57] <Nick Doty> we all clearly enjoy thinking about the protocol and potential problems, but does that also imply a diversity of interested implementers?
[20:51:25] <Christian Huitema> @hardie: that's a general problem with this kind o digital currency. The token is a "coin", you can pay someone with it, but you only know the coin was not spent yet when you try redeem it.
[20:51:37] pardue joins the room
[20:51:41] <leifj> I guess non-transferability is kinda hard to combine with anonymity right?
[20:51:43] <Dave Thaler> My intuition tells me that non-transferability and unlinkability are not mutually exclusive.
[20:51:52] <Jonathan Hoyland> @hardie everyone submits 100 tokens, trusted third party™ spends one token from each, chosen at random, everyone who's token validates gets a proportion of the token pool. Anyone who's token does not validate gets no tokens.
[20:51:59] <carrickdb@jabber.hot-chilli.net> @hardie presumably the cryptographic properties are such that creating a "lug" is prohibitively difficult/unlikely
[20:52:10] <Jonathan Hoyland> whose*
[20:52:17] xp29srs joins the room
[20:52:26] pardue leaves the room
[20:52:42] <Dave Thaler> hard != impossible.  For example, the work christian and david schinazi and others did on privacy in service discovery is an example of interesting work that might be relevant (not sure, but point is crypto might be able to solve).
[20:52:46] jhoyla joins the room
[20:53:00] <dkg> https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-charter
[20:53:26] <hardie> @Jonathan  That would imply you can only pool tokens you "earned" yourself, or you run the risk of losing N more tokens by passing one more bummer.
[20:53:46] <Christian Huitema> This kind of tokens would be very useful in P2P networks, to provide resistance to DDOS without having to actually authenticate users
[20:53:49] <adam> carrickdb@jabber.hot-chilli.net: I mean, a "lug" could be an old, spent token, right?
[20:53:50] <synp> I'm still missing which server has which information.  What does the issuing server know?  What does the relying party know?  What information is kept private and from whom?
[20:53:56] svaldez leaves the room: Connection failed: connection closed
[20:54:04] <hardie> @carrickdb Faking seems easier than that to me, but I may be wrong.
[20:54:46] Greg Wood leaves the room
[20:54:56] jhoyla leaves the room
[20:55:08] tfpauly joins the room
[20:55:09] <kaduk@jabber.org/barnowl> Thanks MT!
[20:55:22] cabo leaves the room
[20:55:32] <Dave Thaler> Another example of anonymity with non-transferability is Intel's EPID (which I think has IPR associated, but point is problem is not intractable).
[20:55:39] cabo joins the room
[20:55:50] johnk leaves the room
[20:55:51] <sftcd> the concept that a human user would choose an issuer here seems wrong
[20:56:01] stf joins the room
[20:56:08] <kaduk@jabber.org/barnowl> Dave Thaler: does that EPID protect against colluding transferrers?
[20:56:15] <hardie> @sftcd agree.  So you get "who gates the gatekeepers" problem.
[20:56:22] sub@jabb.im joins the room
[20:56:32] <mnot> Some are already assuming they'll be able to choose their DoH server; why not add one more choice?
[20:56:56] <hardie> Get your tokens with your DNS resolution?
[20:57:00] <Dave Thaler> @Ben, I don't know for sure but I think it's protected by the overall solution not the EPID algorithm itself
[20:57:01] <sftcd> sure let 'em pick their /128's as well so:-)
[20:57:01] svaldez joins the room
[20:57:06] <Warren Kumari> <Warren is unclear if this is snark or not…>
[20:57:06] <hardie> Present a DNS cookie and get a token?
[20:57:13] <Martin Thomson> pre-commitment by a relying party has to be similarly global in scope as the key commitment the issuer makes
[20:57:17] lpardue joins the room
[20:57:19] <mnot> This is snark, warren — but we're worried it's becoming true.
[20:57:22] <dkg> (reminder: when making a slide deck, please include slide numbers!)
[20:57:32] <Nick Sullivan> How are the chairs expecting us to answer? Jumping in the queue?
[20:57:42] <Ben Schwartz (chair)> Yes
[20:57:44] <mnot> Nick: You are "at the front of the room"
[20:57:46] <Dave Thaler> Hum? :)
[20:58:01] <Warren Kumari> @mnot: Yes, indeed...
[20:58:04] pardue joins the room
[20:58:08] Cullen Jennings joins the room
[20:58:13] <Andrew Campling> Checks and balances needed to avoid yet more centralisation?
[20:58:14] Cullen Jennings leaves the room
[20:58:14] <kaduk@jabber.org/barnowl> Oops, I asked Alex to put slide numbers but missed the chairs' slidess
[20:58:22] svaldez leaves the room
[20:58:33] jhoyla joins the room
[20:58:39] <Martin Thomson> kaduk@jabber.org/barnowl: this is not your responsibility
[20:58:53] <Jim Fenton> I'm still wondering if this isnt something that should go into the RATS WG (although I haven't followed them at all)
[20:58:54] Ais Connolly joins the room
[20:59:10] wilma leaves the room
[20:59:20] <Warren Kumari> I'm still confused why presentation software doesn't *default* to including slide numbers…
[20:59:25] <leifj> are we still just talking about tokens for "human"?
[20:59:41] <mnot> some value of "human"
[20:59:45] <mnot> judged by a machine
[20:59:46] <sftcd> in terms of humming: I'd be positive about exploring this more but not yet for creating a WG - I need to read the drafts TBH;-)
[20:59:53] <kaduk@jabber.org/barnowl> leifj: for "human" and there was a currency-like thing mentioned as a
use case as well
[21:00:16] <Christian Huitema> This architecture can easily drive towards centralization, and a very few "issuers". Each web site that consume the tokens has to explicitly trust the issuers, much like they would trust a bank. In practice, only very few issuers will be trusted by the majority of web sites.
[21:00:20] <leifj> then I don't understand why there will be an "ecosystem"
[21:00:30] svaldez joins the room
[21:00:31] <Martin Thomson> Another thing that I'm concerned about with svaldez' response to the question of which entities to trust.  Having allowlists at clients creates incentives toward centralization.
[21:00:33] svaldez leaves the room
[21:00:45] fmiche@jabb.im joins the room
[21:00:46] <synp> Is it just me or did we just have a long pause?
[21:00:51] <leifj> where is the business-model for running captchas ?
[21:00:53] <adam> Has not been a pause
[21:00:59] <cabo> Warren Kumari: Because presentation software is done by people who care about style more than about getting work done
[21:01:05] <synp> it's on my end, then
[21:01:08] ekr@jabber.org joins the room
[21:01:10] <cabo> Dog is breaking up
[21:01:11] <kaduk@jabber.org/barnowl> I'm having a hard time getting dkg's audio stream, which expresses
partially as pauses
[21:01:11] <carrickdb@jabber.hot-chilli.net> I heard a pause
[21:01:20] <cabo> dkg, DYAC
[21:01:24] ekinnear leaves the room
[21:01:34] merm joins the room
[21:01:39] <dkg> +1 on IETF working on this
[21:01:40] <Dave Thaler> @dkg maybe prefix a text comment with mic:
[21:01:44] jhoyla joins the room
[21:01:46] <Martin Thomson> dkg, you were breaking up, but we got that message :)
[21:01:53] <Stefan Santesson> Is there IPR in this space?
[21:01:54] <dkg> i am concerned about consolidation issues
[21:02:21] <dkg> i think we need multiple implementers and reviewers, and public documentation that arises from processes like what happens in the IETF.
[21:02:40] <leifj> @dkg - everyone does re:Captcha today... and this changes to an ecosystem because we turn it into a "coin"?
[21:03:06] <Martin Thomson> I am concerned about the consolidation effects.  If you have a central ledger (blockchain!), that is a centralization point.  Without a ledger, it seems like the list of issuers and reliers becomes another way toward centralization.
[21:03:10] <dkg> leifj: re:Captcha is also problematic
[21:03:18] <leifj> @dkg I agree!
[21:03:19] <dkg> and more problematic than privacypass, yes
[21:03:19] svaldez joins the room
[21:03:19] xp29srs leaves the room
[21:03:23] <leifj> it is highly problematic!
[21:03:33] <dkg> b/c its controllers can track users
[21:03:37] lpardue joins the room
[21:03:42] <Christian Huitema> Of course, if you don't want the "central bank" aspect of the proposal, you have to invest in some kind of block-chain alternative. Good luck...
[21:03:53] <Nick Doty> (haha, also noticed the q+)
[21:03:54] <leifj> but I'm wondering how changing technology wo incentive for deployment gets you results
[21:04:06] <wseltzer> :)
[21:04:22] <dkg> leifj: if you're asking how we get incentive to deploy, that's a different question
[21:04:28] <Dave Thaler> I'm not convinced it's a "different" problem a RATS, it's a superset of the problem maybe.  I agree it doesn't go in RATS because RATS doesn't do protocol.   Some attestation mechanisms mentioned in RATS (like the vendor-specific EPID) do allow unlinkability I'm told.   So having RATS deal with unlinkability considerations might be ok.   But protocol would be in a separate group.
[21:04:31] <Martin Thomson> Having a system like this might enable reliance more on reputation than Turing test surrogates.  Maybe that is worth some optimism.
[21:04:37] <dkg> but the technology needs to exist to drive deployment
[21:04:45] Eric Vyncke leaves the room
[21:04:52] <leifj> @dkg - thats sorta part of the IETF question: if you don't have interest from deployers all you produce is paper
[21:05:07] <Dave Thaler> (I might be able to be convinced, but I'm just not convinced yet.)
[21:05:07] Kathleen joins the room
[21:05:08] <dkg> but we have a handful of deployers already
[21:05:18] <hardie> @MT where would the BATS implementation be in that direction?
[21:05:24] <Nick Doty> mt: I thought the privacypass approach made it less about your reputation than the Google-recaptcha existing situation
[21:05:26] <leifj> @dkg - thats what I need - who?
[21:05:39] <dkg> go back to the first few slides :)
[21:05:40] <Kathleen> From Dave Thalers comments, I need to read more.
[21:05:43] <kaduk@jabber.org/barnowl> MT: in that I can very strongly authenticate to google that I'm a
human, but don't want to give that to everyone that uses reCAPTCHA?
[21:06:23] <Martin Thomson> Nick Doty: this carries state from one context to another.  that state doesn't need to be "user solved CAPTCHA", it could be "user has a good reputation with me"
[21:06:23] <leifj> @dkg - I missed them :-)
[21:06:23] <dkg> wow
[21:06:46] jhoyla leaves the room
[21:06:47] <Kathleen> I can't see the etherpad link, I joined this chat too late.  Can someone share?
[21:06:56] <sftcd> if there're that many authors, this effort is screwed;-)
[21:07:03] <dkg> Michele Orrù put +1337 😛
[21:07:03] <Jonathan Hoyland> https://etherpad.ietf.org:9009/p/notes-ietf-107-privacypass?useMonospaceFont=true
[21:07:04] jhoyla joins the room
[21:07:25] <kaduk@jabber.org/barnowl> sftcd: how many cooks do you allow in your kitchen?
[21:07:30] <Kathleen> Thank you!
[21:07:34] <sftcd> +1
[21:08:20] m&m leaves the room: Disconnected: Replaced by new connection
[21:08:21] m&m joins the room
[21:08:30] pardue leaves the room
[21:08:31] <Martin Thomson> I hope the chairs are recording the names of everyone who said "+1".  I want stats on how many of those people contribute.
[21:08:31] Cathy Aronson joins the room
[21:08:35] <dkg> https://datatracker.ietf.org/meeting/107/materials/slides-107-privacypass-privacy-pass-charter
[21:08:42] <dkg> slide 3
[21:08:47] <kaduk@jabber.org/barnowl> MT: IIUC the chat history is included in the recording
[21:08:56] <dkg> Martin Thomson: do you do that for hands-raised in in-person meetings?
[21:08:57] Cathy Aronson leaves the room
[21:09:22] <spencerdawkins> @Martin - that's why I wanted the "who will participate" stuff in the jabber room. Webex is ethereal.
[21:09:22] pardue leaves the room
[21:09:26] <Martin Thomson> dkg: this medium offers unique opportunities.  But yes, that has been done.
[21:09:29] <Nick Doty> (were we supposed to say what kind of contribution when we said +1? for the record, I was offering to review, not write or implement)
[21:09:32] jhoyla joins the room
[21:09:41] xp29srs joins the room
[21:09:50] lpardue joins the room
[21:09:54] <dkg> too late, Nick Doty -- you're an author now
[21:10:17] <Nick Doty> dkg, yeah, apparently Martin is writing my name down somewhere
[21:10:26] <Martin Thomson> I said "contribute", and reviews do count.
[21:10:42] <ekr@jabber.org> I don't think we're ready to say that we should start work based on these three  documents
[21:10:51] <ekr@jabber.org> As opposed to in this problem space
[21:11:13] <dkg> spencerdawkins: i see a "recording" red dot in my webex webclient -- does that not include the chat?
[21:11:21] <Ben Schwartz (chair)> ekr: I don't believe the charter names those documents
[21:11:22] watson17 leaves the room
[21:11:23] watson17 joins the room
[21:11:38] <ekr@jabber.org> Ben: the text he just showed names them
[21:12:08] <Adam W. / Stu C.> Question: would the compatibility of unforgeability, unlinkability and untransferability be an IRTF question, not an IETF one?
[21:12:09] lpardue leaves the room
[21:12:12] <sftcd> extensions means what? that wasn't explained that I got
[21:12:13] jhoyla leaves the room
[21:12:27] Cathy Aronson joins the room
[21:12:35] tfpauly leaves the room
[21:12:37] Stefan Santesson leaves the room
[21:12:51] jhoyla leaves the room
[21:12:59] <Ben Schwartz (chair)> ekr: Yes, but the proposed charter text does not
[21:12:59] <tancrede> sftcd could be private metadata bit, public metadata bit, public verifiability, etc.
[21:13:09] <ekr@jabber.org> Ben: OK, well that needs to be clear
[21:13:09] <Jonathan Hoyland> @ekr The charter text doesn't mention the documents.
[21:13:22] <sftcd> so extensions could create a super cookie?
[21:13:29] <Nick Doty> the charter includes goals for architecture, protocol and something in HTTP, but not the specific draft names
[21:13:33] <svaldez> The charter talks about having 3 documents (protocol, architecture, HTTP) but not that we use the existing documents at all.
[21:13:38] <Dave Thaler> Re "IRTF question, not an IETF one", probably yes that's why I said IETF or IRTF or both in my comment, for exactly that reason
[21:13:58] Cathy Aronson leaves the room
[21:14:05] <Adam W. / Stu C.> Thanks Dave, I must of missed it - will go back and look at it :)
[21:14:08] <tancrede> sftcd: it would limit the amount of information that can be transferred.
[21:14:20] <Dave Thaler> my comment was verbal
[21:14:24] <sftcd> @tancrede: sorry don't get that
[21:14:30] Stefan Santesson joins the room
[21:14:43] ekinnear joins the room
[21:15:17] <tancrede> @sftcd: You could allow for one private metadata bit only. So you only convey one bit of information in a token. This is less information than contained in a cookie.
[21:15:18] <Jonathan Hoyland> The IRTF is working on the VOPRF document, so the work is def. going to be split between them.
[21:15:18] tfpauly joins the room
[21:15:25] <Jim Fenton> @sftcd: I was also worried about cuper cookies. I gather that's why you might need a whitelist of issuers.
[21:17:28] <Christian Huitema> +1 martin
[21:17:36] Cathy Aronson joins the room
[21:18:09] mzanaty joins the room
[21:18:22] <svaldez> I think there's a balance between extending to allow additional metadata versus the privacy costs. Different things built on privacy pass and clients may want to have different policies/visions for what sorts of attributes are allowable.
[21:18:22] <ekr@jabber.org> I don't understand what this text means "Issued tokens are unlinkable with other tokens corresponding to the same anonymity set."
[21:18:28] <synp> +1 Martin
[21:18:35] <ekr@jabber.org> Isn't that like the opposite of the meaning of anonymity set
[21:18:48] <kaduk@jabber.org/barnowl> s/with/within/
[21:19:17] armfazh0 joins the room
[21:19:18] armfazh0 leaves the room
[21:19:38] <svaldez> Yeah, I think that text is a bit off. Not sure if Alex meant for that to mean issued tokans are indistinguishable with other tokens or unlinkable with other tokens issued at the same time.
[21:19:42] <kaduk@jabber.org/barnowl> The current charter text does talk about "ecosystem", right?
[21:19:43] <mglt> do we need "corresponding  to the same anonymity set. " ?
[21:19:44] <Martin Thomson> That centralization question is very much part of the concern I just raised.
[21:19:52] lpardue leaves the room
[21:19:53] <Jonathan Hoyland> Perhaps "It is not possible to distinguish between tokens issued in the same anonymity set"
[21:19:59] <ekr@jabber.org> So I think what this is trying to say is that "it must not be possible determine whether two tokens that are issued to users within the same anonymity set are issued to the same user or not"
[21:20:00] <kaduk@jabber.org/barnowl> centralization seems part of "ecosystem"
[21:20:12] <ekr@jabber.org> (I'm not trying to write language, just make sure we agree on what it means)
[21:20:14] Cathy Aronson leaves the room
[21:20:14] <leifj> is there any open code for this around?
[21:20:17] <Christian Huitema> I do believe that the charter shall explicitly mention centralization risk and how to prevent it.
[21:20:18] jhoyla leaves the room
[21:20:29] <Nick Sullivan> +1 on adding centralization as a point to address, perhaps in the architecture doc
[21:20:30] <adam> Agree with Christian
[21:20:31] armfazh leaves the room
[21:20:35] <Andrew Campling> +1
[21:20:36] <kaduk@jabber.org/barnowl> Should we zoom in more on the github tab?
[21:20:40] <Martin Thomson> Part of this question of "anonymity set" requires that clients are aware of the extent of that anonymity set.
[21:20:50] <ekr@jabber.org> indeed
[21:20:50] <tancrede> An "anonymity set" could be all the tokens issued under one specific key commitment.
[21:21:09] <dkg> right, that's the presumption of the current implementation
[21:21:12] arm joins the room
[21:21:14] arm leaves the room
[21:21:24] <Martin Thomson> Yes, but clients need to know whether "anonymity set" is just them or it is larger than that.
[21:21:40] <ekr@jabber.org> So I think this needs some text about what anonymity set is
[21:22:00] <mglt> +1 to ekr
[21:22:07] <dkg> Martin Thomson: i don't know how clients can learn that
[21:22:15] <Jonathan Hoyland> @MT I think there is some mention in the documents of how to prevent servers from offering split views of the world to different actors.
[21:22:19] <Martin Thomson> dkg: that's a very good point.
[21:22:20] zx joins the room
[21:22:22] zx leaves the room
[21:22:27] <ekr@jabber.org> @Jonathan, perhaps but it's not in the charter
[21:22:40] <tancrede> @Martin: Yes, correct, that is also what was driving the discussion around the append-only log
[21:22:52] <Jonathan Hoyland> @ekr I think it should be.
[21:23:02] <ekr@jabber.org> Agreed. I plan to say that so you won't have to :)
[21:23:13] <Peter Wu> who is "frmichau" in WebEx?
[21:23:16] <Martin Thomson> dkg: you can imagine that an "is human" service offered by Cloudflare could be understandable
[21:23:17] <dkg> Martin Thomson: even if the client had the bandwidth to retrieve some sort of proof that there were 100000 other clients, those client could all be spoofed, no?
[21:23:26] <ekr@jabber.org> yes :)
[21:23:30] <Martin Thomson> sybil!
[21:23:37] Russ Housley joins the room
[21:23:43] <dkg> my good friend sybil
[21:23:45] <ekr@jabber.org> so it seems like you might be able to have a log that proved that the origin only had one key
[21:24:07] <Warren Kumari> @dkg: which good friend Sybil?
[21:24:10] <dkg> ekr@jabber.org: right, that's what was discussed in the early slide
[21:24:10] <Martin Thomson> then you also need to know that there is only one origin, right?
[21:24:19] <Warren Kumari> I've got at least 3 of them...
[21:24:23] <kaduk@jabber.org/barnowl> Bruce: you recall my friends Bruce and Bruce, right?
[21:24:23] <dkg> right, which is why the draft contemplates a small number of issuers
[21:24:27] <adam> Warren Kumari: https://www.geeksforgeeks.org/sybil-attack/
[21:24:32] <ekr@jabber.org> @MT, @dkg: right
[21:24:35] <leifj> +1
[21:24:37] <Mark Baushke (Juniper)> @notetakeer Christian Huitema
[21:24:40] <dkg> adam: he's trolling you
[21:24:42] <svaldez> Yeah it would be nice to technically defend from anonymity sets of O(1). Policy requirements is nice and all but not a real protection.
[21:24:49] <Warren Kumari> @adam — yes, I seemed to have been too subtle...
[21:25:07] <Dave Thaler> For example, if it's not just about "is human" in a token, then the question is whether EAT could be used as the token format.   That's part of the discussin of relationship with RATS.
[21:25:13] <Warren Kumari> see the "I've got at least 3 of them"..
[21:25:25] <Jim Fenton> 1 or 2 issuers lowers importance of interoperability, right?
[21:25:28] <kaduk@jabber.org/barnowl> ekr, who are you?
[21:25:59] armfazh joins the room
[21:26:06] <Jonathan Hoyland> @dkg as a strawman, could you have some gossip protocol between global clients?
[21:26:16] <Pete Resnick> @kaduk: He snuck it in there at 0.5 EKR.
[21:26:32] <dkg> carrying more information means carving up your anonymity set
[21:26:36] <Warren Kumari> @Adam: have you read book? 'twas deeply disturbing.
[21:26:39] <Nick Sullivan> The way that issue is addressed right now is that the issuers publish their set of keys and each key corresponds to one bit of information.
[21:26:40] lpardue joins the room
[21:26:41] <adam> Warren Kumari:  ¯\_(ツ)_/¯  I have no clue who knows what. :)
[21:26:45] <adam> I have not
[21:26:53] <leifj> is it just me or has ekr's voice blue-shifted a bit?
[21:26:57] <dkg> Jonathan Hoyland: you could use the current draft as the strawman to argue about instead :)
[21:27:01] <svaldez> Jonathan Hoyland: How do you know that the other clients are real users and not fake bots? (require a privacypass token to gossip about privacypass tokens)
[21:27:11] <kaduk@jabber.org/barnowl> I think we should emphasize that Ekr said "formal analysis" in case
people missed it
[21:27:14] <Warren Kumari> Fair nuff. Jabber is not a good way to carry subtlties...
[21:27:15] <Christian Huitema> +1 EKR proofs!
[21:27:36] <Jonathan Hoyland> @dkg We haven't committed to using the current drafts, so I feel free to generate ad hoc straw people.
[21:27:37] <carrickdb@jabber.hot-chilli.net> +1 also on security proofs
[21:27:38] Cathy Aronson joins the room
[21:28:08] <cabo> Getting more audio gaps now
[21:28:26] <kaduk@jabber.org/barnowl> I lost a bit of Ekr's latest, yes
[21:28:38] Cathy Aronson leaves the room
[21:28:39] <spencerdawkins> Me, too.
[21:28:40] <synp> Nah, ekr sounds like that in real life as well
[21:29:35] <leifj> +1 ERK - "claims"
[21:29:39] amontville leaves the room
[21:29:40] Cullen Jennings joins the room
[21:29:44] <leifj> :-)
[21:30:00] lpardue leaves the room
[21:30:02] <kaduk@jabber.org/barnowl> dkg still not working
[21:30:18] ekinnear leaves the room
[21:30:19] <dkg> mic: more bits means carved up anonymity sets
[21:30:22] Martin Thomson is sad that dkg can't speak
[21:30:22] <sftcd> dkg was trying to send fewer audio bits:-)
[21:30:24] <kaduk@jabber.org/barnowl> We did have someone assert jabber-scribe role to relay the mic
comments, right?
[21:30:39] <Martin Thomson> dkg: yes.
[21:30:47] jhoyla leaves the room
[21:30:53] <Pete Resnick> @dkg: Type into the Etherpad instead of here to get it in the minutes for sure.
[21:30:54] <dkg> limiting the number of bits you can assert is a way to ensure that the issuer can only work with a single anonymity set
[21:31:05] Stefan Santesson leaves the room
[21:31:12] ekinnear joins the room
[21:31:12] tim costello joins the room
[21:31:15] <Jonathan Hoyland> +1 ekr especially as you can simulate sending multiple bits by doing multiple rounds (with different keys) in a single session.
[21:31:20] Stefan Santesson joins the room
[21:31:25] <leifj> yes if a technology involving crypto gets used a lot then the keymanagement problems become bigger
[21:31:25] <ekr@jabber.org> @dkg: absolutely. The way I sort of expect this to work is that the client and server agree on the message to be embedded
[21:31:27] <kaduk@jabber.org/barnowl> (Dan York asserted that, according to my backscroll)
[21:31:35] <ekr@jabber.org> But I agree, all of this needs a pile of analysis
[21:32:14] <Martin Thomson> You need some way to understand what the resulting anonymity set looks like as a result of sending >0 bits.
[21:32:23] <Martin Thomson> That's as true for 1 bit as it is for >1.
[21:32:27] <sftcd> hmm helping ad campaigns is not something that makes me feel more like contributing - that'd be the kind of abuse-case I mentioned before (and yes, I know that others like ads)
[21:32:30] StephenBotzko leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:32:31] Cathy Aronson joins the room
[21:32:46] StephenBotzko joins the room
[21:32:50] <carrickdb@jabber.hot-chilli.net> @sftcd same tbh
[21:33:08] <Dan York> @dkg: Yes, I can relay to the mic
[21:33:15] <leifj> more bits doesn't mean cloudflare will suddenly be able to assert "student" - more /semantic/ means more issuers
[21:33:17] Cathy Aronson leaves the room
[21:33:18] <Martin Thomson> sftcd: you have to realize that this WILL be turned to the purposes of advertisers, but client should be able to choose whether or not to participate
[21:33:55] jhoyla joins the room
[21:34:03] <Dan York> dkg: do you still want me to relay what you said above?
[21:34:05] <Dave Thaler> the client can always opt-out by not using such tokens, no?
[21:34:18] <sftcd> @MT: yep I do realise that (ab)use will occur, not clear to me how a client might not participate
[21:34:18] <dkg> Dan York: i think it's all captured in the notes already, thanks
[21:34:25] <kaduk@jabber.org/barnowl> Hmm, MT and Christian are both outgoing IAB; have we heard from
current-IAB on consolidation in this session?
[21:34:27] tfpauly leaves the room
[21:34:27] <Dan York> Ok!
[21:34:37] <dkg> Dave Thaler: "consent" is really hard to make work in this context
[21:34:48] <leifj> @dkg +1
[21:34:48] <kaduk@jabber.org/barnowl> Dan: Joe read the specific words already from the chair mic
[21:34:49] <ekr@jabber.org> @kaduk: I heard that the new IAB loves centralization
[21:34:52] <Martin Thomson> sftcd: if the requirement is that the client understands the scope of the anonymity set, that provides some handle
[21:34:54] <ekr@jabber.org> :)
[21:35:00] <Martin Thomson> kaduk@jabber.org/barnowl: still technically IAB
[21:35:07] Glen (AMS IT) joins the room
[21:35:12] <Dan York> dkg: feel free to do "MIC:" again and I will be glad to say it.
[21:35:18] Stefan Santesson leaves the room
[21:35:22] <kaduk@jabber.org/barnowl> MT: that's why I said "outgoing" rather than "former" :)
[21:35:24] <dkg> MIC: consolidation is a problem, and a serious one.    This draft is talking about a mechanism that allows us to place some limits on consolidated information brokers.
Room Configuration
[21:35:26] Chatroom configuration modified
[21:35:27] watson17 leaves the room
[21:35:28] <Dan York> @kaduk@jabber.org/barnowl - Ah, thanks
[21:35:29] Stefan Santesson joins the room
[21:35:35] <Ben Schwartz (chair)> Jabber scribes: please insert yourself in the queue and add "as scribe"
[21:35:44] <Jonathan Hoyland> @sftcd Do you think this is similar to TINFOOIL forced "consent" issues?
[21:35:48] watson17 joins the room
[21:36:09] <sftcd> @MT: not clear to me that the size of the anonymity set is a metric that'd help decide whether to send a token or not
[21:36:40] <Martin Thomson> everyone will make their own assessment about whether to participate.  Size of the set is only one criterion.
[21:36:43] <sftcd> @jonathan: I wouldn't go that far (I think)
[21:36:55] tfpauly joins the room
[21:37:00] <sftcd> @MT: by "everyone" you mean people or browser implementers?
[21:37:16] Cathy Aronson joins the room
[21:37:24] <kaduk@jabber.org/barnowl> browser implementers are people, too ;)
[21:37:26] <Martin Thomson> The nature of that set is also important.  Demonstrated interest in a particular form of pornography might have a large set, but still not be something someone is willing to propagate in this way.
[21:37:57] <Martin Thomson> sftcd: Who decides is definitely an important question here.
[21:38:27] Jim Fenton leaves the room
[21:38:36] <carrickdb@jabber.hot-chilli.net> Why is consolidation such a problem? If servers don't like using one or two issuers, can't someone just make a third, fourth, etc?
[21:38:48] <leifj> "centralized set of issueers".... yikes
[21:38:55] <Jonathan Hoyland> @MT I also really object to religion-based advertising. I would _not_ be happy to share even an anonymous token about that.
[21:39:05] Cathy Aronson leaves the room
[21:39:09] <leifj> and golf
[21:39:16] <Ben Schwartz (chair)> carrickdb@jabber.hot-chilli.net: Whether or not I have a token from some issuer is a 1-bit tracking cookie.  33 issuers is enough to identify all humans uniquely.
[21:39:29] <dkg> carrickdb@jabber.hot-chilli.net: consolidation is an ecosystem problem, not something that can be solved by individual changes
[21:40:08] <kaduk@jabber.org/barnowl> mandatory policy documents at issuers along with their key
information, to give legally binding indication of what information
their tokens contain?
[21:40:20] <Jonathan Hoyland> Ben Schwartz (chair) could we make some limit on the number of tokens that a client should ever send on a single connection
[21:40:41] <Ben Schwartz (chair)> Jonathan Hoyland: Then we have to make these connections unlinkable from each other...
[21:40:45] <sftcd> @jonathan: what is a single connection?
[21:40:46] <leifj> @kaduk that approach only works if the user makes rational and informed decisions.
[21:40:58] <leifj> this isn't usually the case when users are faced with trust decisions
[21:41:03] <wseltzer> @kaduk with more p3p echoes
[21:41:17] <kaduk@jabber.org/barnowl> leif: agreed, but that won't stop people from suggesting it
[21:41:22] <Nick Sullivan> 33 keys from the same issuer is enough, 33 distinct issuers doesn't seem like as much of a problem as long as each token can only be redeemed by its issuer.
[21:41:27] <carrickdb@jabber.hot-chilli.net> @Ben I thought the point was that the token is completely anonymous, even if there's one issuer.
[21:41:28] wseltzer neither
[21:41:35] hardie neither
[21:41:35] <leifj> @kaduk maybe write the list of non-patterns for trust
[21:41:42] <leifj> an IANA registry
[21:42:01] <Nick Doty> (when else was p3p being discussed this week?)
[21:42:02] <ekr@jabber.org> @Nick: I *think* you could probably use cookie syncing techniques to merge the issuers
[21:42:02] BEHCET SARIKAYA joins the room
[21:42:12] <Jonathan Hoyland> @sftcd @Ben Schwartz I'm imagining I'm browsing some site and it redirects me through a series of captcha style gates. There should be a limit on the number of tokens I would be willing to redeem to jump those gates.  
[21:42:13] <dkg> i just want to make sure that we get some documents that talk about "redeemer" in the editor's queue (speaking of religious tokens😛)
[21:42:30] <kaduk@jabber.org/barnowl> dkg++
[21:42:34] <leifj> dkg+++
[21:42:36] Cathy Aronson joins the room
[21:42:37] <sftcd> @nick: p3p wasn't "discussed" it was used as a stick to beat someone with:-) forget when though
[21:42:40] <dkg> Jonathan Hoyland: you might not even notice that you're jumping through those gates
[21:42:43] <Martin Thomson> I have no issue with this being an information-type-agnostic mechanism, but we do need to understand how this tool might be used.  And how clients might be able to understand and effectively control it.
[21:43:00] stf leaves the room
[21:43:09] <Jonathan Hoyland> @dkg It could be a feature of the browser / extension.
[21:43:09] lpardue leaves the room
[21:43:28] stf joins the room
[21:43:31] <Martin Thomson> dkg: unfortunately, client == redeemer, so it's really the thing that is the receiver of redemption.
[21:43:32] <wseltzer> @nick I blame @hardie
[21:44:09] <dkg> Martin Thomson: client ≠ redeemer, if i'm understanding the current conversation
[21:44:30] <Martin Thomson> Hmm, I see the client being the one to redeem tokens.  Is that wrong?
[21:44:36] <Christian Huitema> Look at how the Church could have benefited of anonymous tokens in the 16th century when selling tokens to paradise!
[21:44:43] <dkg> hm, i guess when I "redeem" a bottle to get its deposit back from the store, i don't know whehther i'm the redeemer, or the store is the redeemer
[21:44:47] <dkg> Christian Huitema: ha ha
[21:44:58] <tancrede> @ekr: We're going to a world of first party cookies only, so it seems that cookie syncing techniques to merge issuers will not be possible eventually.
[21:45:20] <Ben Schwartz (chair)> First party cookies are sufficient to bind multiple issuers tokens together
[21:45:31] <ekr@jabber.org> @tancrede: hmm.... unfortunately cookie synchng techniques are not limited to cookies.
[21:45:59] <sftcd> @tancrede: do the proponents see a relationship between this work and the reduction in 3rd party cookies?
[21:46:01] Cathy Aronson leaves the room
[21:46:25] lpardue joins the room
[21:46:25] Greg Wood joins the room
[21:46:53] jhoyla joins the room
[21:46:55] <mglt> I think that is better to have it in the charter
[21:47:25] <svaldez> There's a relationship in so far that if 3rd party cookies were always available, then bad-acting issuers would not do PrivacyPass and instead just use 3P cookies to transfer information. Given the reduction in 3P cookies, PrivacyPass should be designed to protect against malicious issuers.
[21:47:53] <Nick Doty> @sfctd: ah yes, it seems like a new life for p3p as "bogeyman used to discourage others"
[21:48:35] <cabo> … and that why this is NOT attestation
[21:48:37] <Jonathan Hoyland> Hmm, like bearer tokens
[21:48:39] <leifj> ah identity metaphysics
[21:49:20] <sftcd> @svaldez: so we're posing as a requirement that we want a mechanism that can resist attempts at being gamed by almost every web site?
[21:50:07] <sftcd> (again I'm not being negative but that may be a high bar)
[21:50:07] ekinnear leaves the room
[21:50:40] <Dave Thaler> +1 cabo
[21:51:14] <Christian Huitema> @ben kaduk -- the research on DigiCash was done in the 80's. Today's problem looks like engineering.
[21:51:24] ekinnear joins the room
[21:51:37] <leifj> "leifj is a student" => "leifj gets student discount" doesn't mean the discount is transferrable
[21:51:38] <svaldez> sftcd: I don't know if I'd go that far, but I think we should have a requirement to limit the amount of damage/privacy leakage a malicious user can pose, even if we don't solve it completely.
[21:51:47] <sftcd> so we are clear that forming a WG means handing over change control right? that last from Alex just seemed to not say that
[21:52:05] Melinda leaves the room
[21:52:08] <sftcd> @svaldez: malicious user meaning a web site though
[21:52:10] petereyee leaves the room
[21:52:11] lpardue joins the room
[21:52:15] <Nick Doty> good work chairs, staff, etc this remote meeting worked well!
[21:52:19] jhoyla joins the room
[21:52:22] <dkg> alxdavids: did you see sftcd ↑
[21:52:26] <svaldez> Err, meant malicious issuer.
[21:52:32] sfuerst leaves the room
[21:52:40] <sftcd> yep
[21:52:40] Glen (AMS IT) leaves the room
[21:52:42] martin.duke leaves the room
[21:52:44] <leifj> thx!
[21:52:53] <sftcd> thanks and good night all1
[21:52:53] jimsch1 leaves the room
[21:52:54] Greg Wood leaves the room
[21:52:54] jon-ietf leaves the room
[21:52:58] oneeyedian leaves the room
[21:52:59] <dkg> thanks, chairs!
[21:52:59] Dave Thaler leaves the room
[21:52:59] Shumon Huque leaves the room
[21:53:00] brandon.maslen leaves the room
[21:53:00] synp leaves the room
[21:53:02] sftcd leaves the room
[21:53:03] whatdafuq leaves the room
[21:53:08] wseltzer leaves the room
[21:53:09] <svaldez> Thanks all.
[21:53:09] sub@jabb.im leaves the room
[21:53:14] armfazh leaves the room
[21:53:18] Yoshiro YONEYA leaves the room
[21:53:19] <tancrede> Thanks
[21:53:22] <Christian Huitema> Bye!
[21:53:22] tancrede leaves the room
[21:53:23] Barry Leiba leaves the room
[21:53:23] Valery Smyslov leaves the room
[21:53:29] Bob Moskowitz leaves the room
[21:53:32] Amelia Andersdotter leaves the room
[21:53:35] leifj leaves the room
[21:53:42] mzanaty leaves the room: Connection failed: connection closed
[21:53:59] Martin Thomson leaves the room
[21:54:00] csperkins leaves the room
[21:54:05] Andrew Campling leaves the room
[21:54:13] jbui leaves the room
[21:54:36] Cathy Aronson joins the room
[21:54:44] Cullen Jennings leaves the room
[21:55:07] xp29srs leaves the room
[21:55:12] svaldez leaves the room
[21:55:35] stf leaves the room
[21:55:37] jhoyla leaves the room
[21:55:39] spencerdawkins leaves the room
[21:55:41] <alxdavids> @sftcd: yes, forming a WG would hand over change rights, apologies if that wasn't made clear!
[21:55:53] Alissa Cooper leaves the room
[21:56:11] merm leaves the room
[21:56:40] tim costello leaves the room
[21:57:06] bhoeneis leaves the room
[21:57:43] Ais Connolly leaves the room
[21:58:17] lpardue joins the room
[21:58:55] Cathy Aronson leaves the room
[21:58:55] jhoyla joins the room
[21:59:30] tfpauly leaves the room
[21:59:34] watson17 leaves the room
[21:59:39] <dkg> alxdavids: i think he left the room already
[21:59:54] tfpauly joins the room
[21:59:55] <dkg> thanks for confirming that you understand the expectations though
[22:00:05] <dkg> and thanks for all the work you're putting into this.  good stuff!
[22:00:25] adam leaves the room
[22:00:40] SM leaves the room
[22:01:49] Dan York leaves the room
[22:02:01] jhoyla joins the room
[22:03:08] Cathy Aronson joins the room
[22:03:42] Adam W. / Stu C. leaves the room
[22:04:27] tim costello joins the room
[22:05:07] joehall leaves the room: Replaced by new connection
[22:05:08] joehall joins the room
[22:05:29] carrickdb@jabber.hot-chilli.net leaves the room
[22:06:10] Cathy Aronson leaves the room
[22:06:16] lpardue joins the room
[22:06:51] m&m leaves the room
[22:07:54] tim costello leaves the room
[22:07:58] tim costello joins the room
[22:08:09] jhoyla leaves the room
[22:08:53] Ben Schwartz (chair) leaves the room
[22:09:20] Ben Campbell leaves the room
[22:09:40] Ben Schwartz (chair) joins the room
[22:09:46] drazen leaves the room: Disconnected: Broken pipe
[22:09:52] jhoyla joins the room
[22:10:02] lpardue joins the room
[22:10:10] fmiche@jabb.im leaves the room: Connection failed: connection closed
[22:10:12] <alxdavids> @dkg no problem, thank you (and to everyone else) for participating! It was really useful.
[22:10:55] lpardue leaves the room
[22:11:00] alxdavids leaves the room
[22:11:05] Sofia Celi joins the room
[22:11:45] drazen joins the room
[22:12:13] Warren Kumari leaves the room
[22:13:37] Russ Housley leaves the room
[22:13:49] lpardue joins the room
[22:15:26] jhoyla joins the room
[22:15:35] Karen O'Donoghue leaves the room
[22:16:08] Cathy Aronson joins the room
[22:17:18] kaduk@jabber.org/barnowl leaves the room
[22:18:30] lpardue joins the room
[22:18:30] jhoyla joins the room
[22:20:32] joehall leaves the room
[22:20:43] mnot leaves the room
[22:20:55] Cathy Aronson leaves the room
[22:21:05] lpardue leaves the room
[22:22:57] jhoyla leaves the room
[22:23:12] Sofia Celi leaves the room
[22:23:12] tfpauly leaves the room
[22:23:12] lpardue leaves the room
[22:23:12] ekinnear leaves the room
[22:23:12] jhoyla leaves the room
[22:23:12] lpardue leaves the room
[22:23:12] lpardue leaves the room
[22:23:12] lpardue leaves the room
[22:23:12] jhoyla leaves the room
[22:23:12] jhoyla leaves the room
[22:23:12] jhoyla leaves the room
[22:23:13] Sofia Celi leaves the room
[22:24:22] lpardue leaves the room
[22:24:37] Sofia Celi joins the room
[22:25:30] jhoyla leaves the room
[22:25:55] Nick Sullivan leaves the room
[22:26:17] lpardue joins the room
[22:27:26] jhoyla joins the room
[22:31:33] Nick Doty leaves the room
[22:31:58] StephenBotzko leaves the room: Disconnected: BOSH client silent for over 60 seconds
[22:32:15] Christian Huitema leaves the room: Disconnected: closed
[22:33:50] drazen leaves the room: Disconnected: closed
[22:37:08] BEHCET SARIKAYA leaves the room
[22:37:22] Cindy Morgan leaves the room
[22:37:28] Samuel Weiler leaves the room
[22:39:43] Wes Hardaker leaves the room: Disconnected: closed
[22:42:01] sofia leaves the room
[23:00:05] joehall joins the room
[23:00:19] joehall leaves the room
[23:02:07] lpardue leaves the room
[23:12:56] Dirk Balfanz leaves the room
[23:18:33] Alexey Melnikov leaves the room
[23:20:12] jhoyla leaves the room
[23:21:52] jhoyla joins the room
[23:23:21] Olaf Kolkman leaves the room
[23:27:02] Ben Schwartz (chair) joins the room
[23:27:02] Ben Schwartz (chair) leaves the room
[23:39:37] Peter Wu leaves the room: Disconnected: BOSH client silent for over 60 seconds