[{"author": "Jonathan Hammell", "text": "I can take notes<br/>", "time": "2022-03-24T12:01:25Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Thanks Jonathan!<br/>", "time": "2022-03-24T12:01:42Z"}, {"author": "Mark McFadden", "text": "I am here if there is time later.<br/>", "time": "2022-03-24T12:02:34Z"}, {"author": "sftcd", "text": "nit: space is a bit of an odd term here, but I see why you chose it (no need to discuss in the room/via-voice)<br/>", "time": "2022-03-24T12:13:06Z"}, {"author": "David Schinazi", "text": "It reminds me of Inspector SpaceTime (from the TV series Community)<br/>", "time": "2022-03-24T12:13:41Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "It's a great setup for lines like \"private throughout the entire<br/>space-time continuum!\"<br/>", "time": "2022-03-24T12:13:44Z"}, {"author": "Robin Wilton", "text": "\"Time separation\" here essentially means that issuance and redemption are asynchronous.<br/>", "time": "2022-03-24T12:13:53Z"}, {"author": "David Schinazi", "text": "I prefer to think of it as time travel<br/>", "time": "2022-03-24T12:14:11Z"}, {"author": "Robin Wilton", "text": "All my time travel is synchronous.<br/>", "time": "2022-03-24T12:14:36Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Time separation needs to be a little bit stronger than just<br/>asynchronous, since even then there would be some correlation.<br/>", "time": "2022-03-24T12:14:37Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I guess the \"space\" idea is that someone could link per-proxy<br/>information but not know about the \"client\" itself<br/>", "time": "2022-03-24T12:14:45Z"}, {"author": "Robin Wilton", "text": "@svaldez Yes; asynchronicity is necessary but insufficient.<br/>", "time": "2022-03-24T12:15:09Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Space being about the \"source\" of the client's requests. You could<br/>have an \"anonymous request\" that doesn't include cookies/state and one<br/>that does, but those might still not be space separated since their IP<br/>address might be the same.<br/>", "time": "2022-03-24T12:16:29Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "I would prefer to not punt centralization *entirely* to Mark's doc<br/>", "time": "2022-03-24T12:19:25Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Tommy is still slightly choppy (has been all week, IIRC).<br/>But basically intelligible...<br/>", "time": "2022-03-24T12:20:46Z"}, {"author": "sftcd", "text": "@svaldez: yep, but I guess two different IPs from the same /64 wouldn't always be \"space-separated\" and something like screen-size or other client fingerprints might provide similar linkage - not that privacypass has gotta be perfect but might be good to be more precise about what space means<br/>", "time": "2022-03-24T12:21:02Z"}, {"author": "Benjamin Schwartz", "text": "Try mute/unmute<br/>", "time": "2022-03-24T12:21:05Z"}, {"author": "Ted Hardie", "text": "Yes, it is choppy<br/>", "time": "2022-03-24T12:21:07Z"}, {"author": "Rich Salz", "text": "maybe next time dont particiapate from your private helicopter.<br/>", "time": "2022-03-24T12:21:30Z"}, {"author": "Rich Salz", "text": "speaking slowly helps a great deal BTW<br/>", "time": "2022-03-24T12:21:45Z"}, {"author": "Jana Iyengar", "text": "you're still choppy, so keep talking slowly, it's helpful<br/>", "time": "2022-03-24T12:24:23Z"}, {"author": "Ted Hardie", "text": "Could we have more than one origin name in the struct, for cases like youtube.com/google.com where the two are not the same but the redemption mechanics might be?<br/>", "time": "2022-03-24T12:25:04Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "the terminology of the presentation language lends itself to punnery,<br/>with the proposal sounding like it wants a transluscent origin_name<br/>rather than an opaque one (i.e., with some internal structure but<br/>retaining some opaque bits)<br/>", "time": "2022-03-24T12:27:07Z"}, {"author": "Jonathan Hammell", "text": "Who is speaking (Steven?)<br/>", "time": "2022-03-24T12:30:06Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Steven Valdez<br/>", "time": "2022-03-24T12:30:12Z"}, {"author": "Jonathan Hammell", "text": "Thanks!<br/>", "time": "2022-03-24T12:30:24Z"}, {"author": "David Schinazi", "text": "If this isn't the same \"origin\" as the Web concept, maybe we should rename it to something else?<br/>", "time": "2022-03-24T12:30:56Z"}, {"author": "sftcd", "text": "tommy's very good at keeping to the speaking-slowly, doubt I could do it;-)<br/>", "time": "2022-03-24T12:31:58Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "Well, it's kind of a context in which the token would be<br/>redeemable...oh wait, we already have a redemption_context<br/>", "time": "2022-03-24T12:32:02Z"}, {"author": "npd", "text": "it kind of seems like \"origin\" and \"context\" are both opaque strings selected by the origin<br/>", "time": "2022-03-24T12:32:24Z"}, {"author": "npd", "text": "+1 kaduk<br/>", "time": "2022-03-24T12:32:29Z"}, {"author": "Christopher Wood", "text": "It currently _is_ the origin as in the Web context<br/>", "time": "2022-03-24T12:32:50Z"}, {"author": "Christopher Wood", "text": "@npd the client is expected to check that origin_name, if present, matches that of the origin it's interacting with<br/>", "time": "2022-03-24T12:33:25Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "We might also consider how things degrade if different origins<br/>independently select truly opaque \"origin\" values that happen to<br/>collide.&nbsp;&nbsp;IIUC it degrades pretty gracefully, but maybe there is an<br/>attack lurking there.<br/>", "time": "2022-03-24T12:33:33Z"}, {"author": "Christopher Wood", "text": "(I think we have text to that effect, but I can't remember offhand)<br/>", "time": "2022-03-24T12:33:36Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "@Chris I just heard Steven saying that it was truly opaque...<br/>", "time": "2022-03-24T12:33:54Z"}, {"author": "Christopher Wood", "text": "This slide should clear things up =)<br/>", "time": "2022-03-24T12:34:14Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "@kaduk: Its not currently opaque, was mentioning it as a possibility<br/>to move to. Not sure its the right approach.<br/>", "time": "2022-03-24T12:34:22Z"}, {"author": "npd", "text": "I'm unclear how this will work with clearing cookies<br/>", "time": "2022-03-24T12:34:26Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "svaldez: ah, thanks.&nbsp;&nbsp;(It is 0530h here, after all.)<br/>", "time": "2022-03-24T12:34:47Z"}, {"author": "Christopher Wood", "text": "Issue for multiple origin names in the TokenChallenge: <a href=\"https://github.com/ietf-wg-privacypass/base-drafts/issues/108\" rel=\"nofollow\">https://github.com/ietf-wg-privacypass/base-drafts/issues/108</a><br/>", "time": "2022-03-24T12:35:29Z"}, {"author": "npd", "text": "given that one likely implementation is that your login identity/cookies with the attester is necessary<br/>", "time": "2022-03-24T12:35:29Z"}, {"author": "Christopher Wood", "text": "(Thanks, Ted!)<br/>", "time": "2022-03-24T12:35:32Z"}, {"author": "Ted Hardie", "text": "Thanks for writing up the issue.<br/>", "time": "2022-03-24T12:35:53Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "Particularly, origin vs site is a bit tricky on the web site. Does<br/>foo.origin.com and bar.origin.com have to request separate per-origin<br/>tokens. Is there a way to indicate *.origin.com or are the only<br/>options global tokens or single-origin tokens.<br/>", "time": "2022-03-24T12:36:46Z"}, {"author": "npd", "text": "it seems like the user should discard the tokens when they clear cookies ... but also that they'll need to log in again with the same identity in order to get more tokens. doesn't that mean that their identity will be linkable?<br/>", "time": "2022-03-24T12:36:46Z"}, {"author": "Tommy Pauly", "text": "@npd: if you're using a separate attester than the origin, you're not really logging back into that origin<br/>", "time": "2022-03-24T12:37:37Z"}, {"author": "Tommy Pauly", "text": "So for the split case, you don't want to be able to be tracked<br/>", "time": "2022-03-24T12:37:49Z"}, {"author": "Benjamin Schwartz", "text": "Maybe the cross-origin problem could be solved by iframing a shared origin...<br/>", "time": "2022-03-24T12:38:17Z"}, {"author": "Tommy Pauly", "text": "If the client allowed that, it could<br/>", "time": "2022-03-24T12:38:36Z"}, {"author": "Tommy Pauly", "text": "But it may be nicer to have an explicit list and ensure that the first-party origin is in the list<br/>", "time": "2022-03-24T12:38:59Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "bemasc: I'd guess some clients wouldn't want to support that or the<br/>higher complexity would be a trade off.<br/>", "time": "2022-03-24T12:39:07Z"}, {"author": "Benjamin Schwartz", "text": "&gt;= 0?<br/>", "time": "2022-03-24T12:40:45Z"}, {"author": "npd", "text": "is the goal to provide more privacy in the paywall context? or just to make paywalls harder for users to get around?<br/>", "time": "2022-03-24T12:46:27Z"}, {"author": "kaduk@jabber.org/barnowl", "text": "This \"private token buckets\" only on the attester is giving me strong<br/>vibes of Robin's question in SAAG, regarding how we think about<br/>keeping attester and issuer separate<br/>", "time": "2022-03-24T12:46:56Z"}, {"author": "Tommy Pauly", "text": "For the paywall case, it's to allow paywalls to work when you have IP address privacy. Because otherwise you just get totally blocked. And now you wouldn't.<br/>", "time": "2022-03-24T12:47:15Z"}, {"author": "Ted Hardie", "text": "Can't the user generate a new client secret in orer to get past this?<br/>", "time": "2022-03-24T12:47:24Z"}, {"author": "Tommy Pauly", "text": "@Ted if the client generates a new secret, the Asstester will learn that because it will collide with the calculated identifier from the issuer<br/>", "time": "2022-03-24T12:47:58Z"}, {"author": "Tommy Pauly", "text": "So the attester can detect a malicious client gaming the system<br/>", "time": "2022-03-24T12:48:10Z"}, {"author": "Ted Hardie", "text": "@Tommy okay, thanks.&nbsp;&nbsp;It has to at least re-initiate a relationship with the attester to do that, and the attester can manage this.<br/>", "time": "2022-03-24T12:48:50Z"}, {"author": "Tommy Pauly", "text": "@npd the other big use case is being able to guarantee that a given device is only able to try to create &lt;N accounts per time window, etc<br/>", "time": "2022-03-24T12:49:03Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "If its possible for the client to generate fresh accounts with the<br/>attester, then they could easily bypass some of the limits.<br/>", "time": "2022-03-24T12:49:51Z"}, {"author": "Tommy Pauly", "text": "@Ted right, it would need to have a new identity from the attester's perspective. If this was just based on IP address, then it's equivalent to the case where rate limiting was based on IP. But attesters can also require stronger identity.<br/>", "time": "2022-03-24T12:49:55Z"}, {"author": "npd", "text": "@tommy I'm more interested in working on that use case (account creation limits). going to great lengths to make it harder for users to clear state so that they can't read articles is less motivating<br/>", "time": "2022-03-24T12:50:34Z"}, {"author": "Tommy Pauly", "text": "Yes, I think that the account creation limits is the most compelling<br/>", "time": "2022-03-24T12:50:57Z"}, {"author": "svaldez@jabber.hot-chilli.net/barnowl", "text": "This construction lets you do that without needing to reveal every<br/>target origin the user to the attester.<br/>", "time": "2022-03-24T12:55:37Z"}, {"author": "npd", "text": "I'm not clear whether the use case is actually for paywall metering or for countering abuse -- they seem pretty distinct<br/>", "time": "2022-03-24T13:00:18Z"}, {"author": "Robin Wilton", "text": "Thanks everyone<br/>", "time": "2022-03-24T13:00:23Z"}, {"author": "npd", "text": "has the user created 10 different accounts with my bank this week? has the user read 10 different articles on my site this week? these don't seem like similar questions<br/>", "time": "2022-03-24T13:01:47Z"}]