Client Implementation in Go

[dhaavi]

Hello 👋

We are thinking about using Privacy Pass for anonymized authorization for a VPN-like service.

Currently we are getting to learn Privacy Pass and the server code a little closer. If we end up choosing Privacy Pass, we would start implementing the client functionality in Go. Here is where I have a couple questions:

• Is a client implementation in Go something you would also be interested in?
• Would you like a PR for it?
• Is there anything you would like us to know before starting? Pitfalls, dragons or the like...

We are naturally not expecting you to help us; we would do the implementation ourselves and have it audited by a cryptographer. Just wanted to communicate and ask beforehand.

[armfazh]

Hi @dhaavi , a Go implementation of Privacy Pass is something really useful.
We recommend to keep track on the changes happening on VOPRF draft and PrivacyPass working group, so the implementation remain compliant with the latest version.

[dhaavi]

Hey @armfazh, thanks for chiming in.

We're not actually creating a new implementation, but just adding some client functionality to what this repo already offers.

Adding client side functions wasn't as difficult as expected, as most of the logic was already in the tests. It just threw me off when the "client" in the tests started to use the server's private key.

I would like to create a PR for this (and a couple other) changes. Can a maintainer comment on that?
(I assume that you, @armfazh, don't have merge rights, correct?)

Also, would you prefer a bigger PR with more changes or many little ones?

[chris-wood]

@dhaavi can you say more about your use case? In particular:

• What sort of requirements do you have for key rotation?
• How will you ensure clients get the expected public key needed to verify tokens?
• Do tokens need to carry any additional attributes beyond a single bit?
• Do the tokens need to be verifiable by parties without the issuance private key?

[dhaavi]

Hey @chris-wood, thank you for your reply!

@dhaavi can you say more about your use case?

Of course! Here you go:

• What sort of requirements do you have for key rotation?

For now, none. The parent system is versioned, which we can use for manual key rotation or breaking changes.

• How will you ensure clients get the expected public key needed to verify tokens?

We ship it in the binary of the client.

• Do tokens need to carry any additional attributes beyond a single bit?

For now, no. But it would be nice to have some additional attributes in the future.

• Do the tokens need to be verifiable by parties without the issuance private key?

Yes, this would be very helpful.

---

I just realized that I somehow managed to mistake @armfazh for an external contributor. 🤦 Sorry about that!
Thanks a lot both of you!

[skyken9966]

Christopher Wood ***@***.***> 于 2021年11月5日周五 下午9:57写道：

…

@dhaavi <https://github.com/dhaavi> can you say more about your use case? In particular: - What sort of requirements do you have for key rotation? - How will you ensure clients get the expected public key needed to verify tokens? - Do tokens need to carry any additional attributes beyond a single bit? - Do the tokens need to be verifiable by parties without the issuance private key? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASEIZBQFNIRNJY7UCH7M4ZLUKPWFRANCNFSM5G4IXCLA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.