[{"author": "Robin Wilton", "text": "

Hi Joe

", "time": "2022-11-11T12:00:07Z"}, {"author": "Nick Doty", "text": "

it's not a bitter place to end at all

", "time": "2022-11-11T12:00:55Z"}, {"author": "Nick Doty", "text": "

can someone remind us of the timeline of reviews for the core docs?

", "time": "2022-11-11T12:02:39Z"}, {"author": "Tommy Pauly", "text": "

The WGLC ends next friday

", "time": "2022-11-11T12:03:33Z"}, {"author": "Jonathan Hoyland", "text": "

How does Sybil protection work here?

", "time": "2022-11-11T12:07:53Z"}, {"author": "Nikita Borisov", "text": "

AIUI the attester verifies client identity and is responsible for sybil protection

", "time": "2022-11-11T12:08:39Z"}, {"author": "Nick Doty", "text": "

the origin here chooses a singular issuer, and gives the client a particular key to use?

", "time": "2022-11-11T12:09:21Z"}, {"author": "Jonathan Hoyland", "text": "

@Nikita Borisov Gotcha, makes sense

", "time": "2022-11-11T12:10:27Z"}, {"author": "Benjamin Schwartz", "text": "

The \"blinding\" here is actually symmetric encryption effectively, right?

", "time": "2022-11-11T12:11:23Z"}, {"author": "Richard Barnes", "text": "

adding ZKP seems like quite a big change, +1 to skipping

", "time": "2022-11-11T12:21:08Z"}, {"author": "Jonathan Hoyland", "text": "

Don't object to skipping, but def. seems an avenue worth exploring.

", "time": "2022-11-11T12:21:39Z"}, {"author": "Jonathan Hoyland", "text": "

If the crypto in your protocol can be described as \"very cool\" you probably don't want it in your protocol :joy:

", "time": "2022-11-11T12:22:40Z"}, {"author": "Steven Valdez", "text": "

Its not a massive change to the core privacypass protocol itself, but yeah would need an extension in the crypto to support.

", "time": "2022-11-11T12:22:48Z"}, {"author": "Jonathan Hoyland", "text": "

#MakeCryptoBoringAgain

", "time": "2022-11-11T12:23:19Z"}, {"author": "Richard Barnes", "text": "

to be clear, i don't think the JOSE ZKP stuff is fully general ZKP

", "time": "2022-11-11T12:23:35Z"}, {"author": "Richard Barnes", "text": "

but it might be enough to address what PrivacyPass needs

", "time": "2022-11-11T12:23:47Z"}, {"author": "Nikita Borisov", "text": "

is this the relevant JOSE document? https://www.ietf.org/id/draft-jmiller-jose-json-web-proof-00.html

", "time": "2022-11-11T12:24:58Z"}, {"author": "Richard Barnes", "text": "

@Nikita there are a few more docs, full repo here: https://github.com/json-web-proofs/json-web-proofs

", "time": "2022-11-11T12:26:33Z"}, {"author": "Nikita Borisov", "text": "

@Richard Barnes thank you!

", "time": "2022-11-11T12:27:04Z"}, {"author": "John Bradley", "text": "

That document may be adopted by the WG. It describes the container not the specific ZKP algorithm.

", "time": "2022-11-11T12:27:58Z"}, {"author": "Nick Doty", "text": "

the origin is choosing the acceptable issuer, but I would think that the origin shouldn't be able to provide any extra detail to pass from the client to the issuer. and agree that having a good key consistency system would generally limit those risks.

", "time": "2022-11-11T12:30:47Z"}, {"author": "Richard Barnes", "text": "

i think the main ZKP people have in mind is proof of possession of a BBS signature https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/

", "time": "2022-11-11T12:31:00Z"}, {"author": "Jonathan Hoyland", "text": "

I'd also like to know / understand the answer.

", "time": "2022-11-11T12:31:48Z"}, {"author": "Jonathan Hoyland", "text": "

So could that discussion happen on-list please?

", "time": "2022-11-11T12:32:03Z"}, {"author": "Nikita Borisov", "text": "

key blinding basically takes an DSA key (x, g^x) and blinds it to (x*r, g^{x*r})

", "time": "2022-11-11T12:32:04Z"}, {"author": "Nikita Borisov", "text": "

FWIW, the ZKP I was using is a a basic conjunction of DLEQ statements

", "time": "2022-11-11T12:34:30Z"}, {"author": "Jonathan Hoyland", "text": "

Putting stuff into an \"Anti-Fraud\" group sides like the opposite of what we want?

", "time": "2022-11-11T12:35:23Z"}, {"author": "Richard Barnes", "text": "

You want fraud?

", "time": "2022-11-11T12:35:38Z"}, {"author": "Jonathan Hoyland", "text": "

Anti-fraud is for defending servers against clients, PP is about defending clients against servers.

", "time": "2022-11-11T12:35:52Z"}, {"author": "Jonathan Hoyland", "text": "

All their decisions will be weighted towards the servers

", "time": "2022-11-11T12:36:32Z"}, {"author": "Alex Chernyakhovsky", "text": "

How is PP defending clients against servers?

", "time": "2022-11-11T12:36:32Z"}, {"author": "Richard Barnes", "text": "

it's about both, providing certain guarantees to the server and certain guarantees to the client

", "time": "2022-11-11T12:36:35Z"}, {"author": "Nikita Borisov", "text": "

I wouldn't say that, it's giving the servers a way to defend against clients without having the clients lose privacy

", "time": "2022-11-11T12:36:38Z"}, {"author": "Nick Doty", "text": "

privacypass is about defending both, right?

", "time": "2022-11-11T12:36:45Z"}, {"author": "Daniel Gillmor", "text": "

always better to remove the word \"trust\"

", "time": "2022-11-11T12:36:46Z"}, {"author": "Tommy Pauly", "text": "

Well, PP is a way to have a compromise -- you get anti-fraud without harming client privacy

", "time": "2022-11-11T12:36:47Z"}, {"author": "Jonathan Hoyland", "text": "

PP is protecting clients from servers by stopping servers linking their requests together.

", "time": "2022-11-11T12:37:32Z"}, {"author": "Tommy Pauly", "text": "

While still attesting to some property about the client in the abstract (which is the part that benefits servers)

", "time": "2022-11-11T12:38:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

Right, if we wanted to protect the clients from the servers by making things unlinkable, we tell people to use Tor

", "time": "2022-11-11T12:38:27Z"}, {"author": "Alex Chernyakhovsky", "text": "

PP makes it such that your use of Tor doesn't give you infinitely many captcha challenges because of other bad actors on those same IPs producing abuse

", "time": "2022-11-11T12:38:47Z"}, {"author": "Nikita Borisov", "text": "

I think of privacy pass as trying to be no more linkable than access without privacy pass. It does not add new unlinkability features, unlike OHTTP/Tor

", "time": "2022-11-11T12:38:55Z"}, {"author": "Tommy Pauly", "text": "

That's a good way of thinking of it, yes

", "time": "2022-11-11T12:39:28Z"}, {"author": "Tommy Pauly", "text": "

It's goal is to not add linkability, rather than explicitly removing linkability

", "time": "2022-11-11T12:39:55Z"}, {"author": "Daniel Gillmor", "text": "

it's a harm reduction approach

", "time": "2022-11-11T12:40:16Z"}, {"author": "Jonathan Hoyland", "text": "

From the original PP paper:
\nimage.png

\n
", "time": "2022-11-11T12:40:18Z"}, {"author": "Jonathan Hoyland", "text": "

Literally property one of the protocol

", "time": "2022-11-11T12:40:37Z"}, {"author": "Tommy Pauly", "text": "

Yes, and the documents still talk about unlinkability

", "time": "2022-11-11T12:40:42Z"}, {"author": "Tommy Pauly", "text": "

But that really means they don't add linkability

", "time": "2022-11-11T12:40:57Z"}, {"author": "Tommy Pauly", "text": "

If I use tokens from my same IP address all the time it doesn't help me

", "time": "2022-11-11T12:41:11Z"}, {"author": "Tommy Pauly", "text": "

Privacy pass didn't link me, but it didn't stop me from being linked either

", "time": "2022-11-11T12:41:23Z"}, {"author": "Daniel Gillmor", "text": "

as usual, academic descriptions do not explicitly say the \"assuming a spherical cow\" part out loud

", "time": "2022-11-11T12:41:29Z"}, {"author": "Richard Barnes", "text": "

+1 Tommy

", "time": "2022-11-11T12:41:33Z"}, {"author": "Daniel Gillmor", "text": "

they work on their specific domain, and leave the rest of the world as an abstraction

", "time": "2022-11-11T12:41:52Z"}, {"author": "Mirja K\u00fchlewind", "text": "

it enables to implement unlinkability

", "time": "2022-11-11T12:42:16Z"}, {"author": "Daniel Gillmor", "text": "

this is the risk of depending only on formal methods - it's easy to forget the difference between the world modeled by the formal methods and the larger world

", "time": "2022-11-11T12:42:31Z"}, {"author": "Daniel Gillmor", "text": "

which is not to say that formal proofs are bad -- they're critically important; just limited to the domains where they operate

", "time": "2022-11-11T12:43:02Z"}, {"author": "Jonathan Hoyland", "text": "

Fair enough. Spherical cows in a vacuum aren't representative of the real world.

", "time": "2022-11-11T12:43:42Z"}, {"author": "Daniel Gillmor", "text": "

right, as protocol designers we need to both take the formal proofs seriously, and understand what parts they don't cover and how those other pieces have an impact on the higher-level goals.

", "time": "2022-11-11T12:45:14Z"}, {"author": "Jonathan Hoyland", "text": "

This paper might be of interest to people here actually:
\nPaper: https://ieeexplore.ieee.org/abstract/document/9799315
\nSlides: https://ssr2022.com/slides/FormalisingLinkedDataBasedVerifiableCredentials.pdf
\nAbstract:

\n
\n

In this paper, we propose a formal definition for Linked-Data based verifiable credential to enable secure selective disclosure among one or multiple verifiable credentials a user has. Previous schemes considered using a single verifiable credential and could not hide the user's identifying information when performing selective disclosure. We pro-pose the first Linked-Data based verifiable credentials that can perform selective disclosure free from the restrictions the previous scheme had, and prove its property. We also discuss a novel use of combining multiple certificates issued by independent issuers to still allow users to perform selective disclosure on the set of credentials. Our scheme has been implemented as an open source Web-based application that generates a verifiable presentation for a given selection of attributes. The performance evaluation is also provided in the paper.

\n
", "time": "2022-11-11T12:45:35Z"}, {"author": "Nick Doty", "text": "

+1 to the question, I'm not sure we are far along enough on the web side to be confident that we won't need any changes

", "time": "2022-11-11T12:46:22Z"}, {"author": "Philipp Pfeiffenberger", "text": "

+1 -- we are making progress on collecting requirements in the W3C AFCG, but we have yet to stack rank and really flesh them out.

", "time": "2022-11-11T12:47:57Z"}, {"author": "Nick Doty", "text": "

it's been an early morning for me, but what I heard is that the Private Access Token implementation isn't currently using the rate-limiting token extensions, but is testing it out?

", "time": "2022-11-11T12:52:01Z"}, {"author": "Tommy Pauly", "text": "

Correct, type 2 basic tokens are being used in production, and type 3 rate limited tokens are currently are testable but not used in production

", "time": "2022-11-11T12:53:03Z"}, {"author": "Tommy Pauly", "text": "

Early morning here too =)

", "time": "2022-11-11T12:53:13Z"}, {"author": "Jonathan Hoyland", "text": "

It might be nominally afternoon here, but I'm tired anyway :joy:

", "time": "2022-11-11T12:53:48Z"}, {"author": "Mark McFadden", "text": "

I'd be willing to revive the consolidation draft that I originally contributed.

", "time": "2022-11-11T12:54:21Z"}, {"author": "Nick Doty", "text": "

do we want to wait and see how it actually gets used and what problems arise and what is needed?

", "time": "2022-11-11T12:55:34Z"}, {"author": "Jonathan Hoyland", "text": "

Another plug for the Formal Methods at the IETF Research Group to be formed.

", "time": "2022-11-11T12:58:13Z"}, {"author": "Jonathan Hoyland", "text": "

The ProVerif work is a formal analysis

", "time": "2022-11-11T12:58:53Z"}, {"author": "Jonathan Hoyland", "text": "

Technically distinct from a formal verification.

", "time": "2022-11-11T12:59:06Z"}, {"author": "Daniel Gillmor", "text": "

+1 philipp for explicitly identifying some core tensions of this work.

", "time": "2022-11-11T12:59:52Z"}, {"author": "Jonathan Hoyland", "text": "

(FA proves the design is correct, FV proves that a particular piece of code implements the design.)

", "time": "2022-11-11T13:00:20Z"}, {"author": "Daniel Gillmor", "text": "

thanks for the clarification, Hoyland

", "time": "2022-11-11T13:00:41Z"}, {"author": "Nikita Borisov", "text": "

why wouldn't these discussions be in the architecture?

", "time": "2022-11-11T13:00:43Z"}, {"author": "Daniel Gillmor", "text": "

Hoyland: would your hypothetical \"formal methods\" group do both FA and FV?

", "time": "2022-11-11T13:01:27Z"}, {"author": "Steven Valdez", "text": "

It seems like some of these considerations would be dependent on what the higher level system/usecase building on top of privacypass is, not sure how much can be generalized across all the different ways of using privacypass.

", "time": "2022-11-11T13:02:08Z"}, {"author": "Jonathan Hoyland", "text": "

That would be my preference. We had a side meeting yesterday where it was suggested we just focus on formal specification (i.e. the first step of FA or FV).

", "time": "2022-11-11T13:02:10Z"}, {"author": "Daniel Gillmor", "text": "

so there's FA and FV and FS -- any other Fs we should know about?

", "time": "2022-11-11T13:02:33Z"}, {"author": "Daniel Gillmor", "text": "

i'm sorry i missed that side meeting

", "time": "2022-11-11T13:02:56Z"}, {"author": "Jonathan Hoyland", "text": "

Probably, but those are the only ones I know about :joy:

", "time": "2022-11-11T13:03:07Z"}, {"author": "Nikita Borisov", "text": "

big thanks to notetakers!

", "time": "2022-11-11T13:03:35Z"}, {"author": "Jonathan Hoyland", "text": "

Oh, Formal Methods as the general / overarching name.

", "time": "2022-11-11T13:03:40Z"}, {"author": "Daniel Gillmor", "text": "

right.

", "time": "2022-11-11T13:03:57Z"}, {"author": "Daniel Gillmor", "text": "

was that side meeting recorded?

", "time": "2022-11-11T13:04:05Z"}, {"author": "Nick Doty", "text": "

:wave: safe travels to those of you traveling

", "time": "2022-11-11T13:04:15Z"}, {"author": "Robin Wilton", "text": "

Kudos to Florence for that! Amazing speed and accuracy.

", "time": "2022-11-11T13:04:31Z"}]