egregors / passkey

🔑 Go library for implementing WebAuthn services 🗝️
MIT License
12 stars 2 forks source link

Bringup the Native Passkey GUI in a browser #26

Closed gedw99 closed 1 month ago

gedw99 commented 1 month ago

I was thinking about this and just now found an example by accident, so just wanted to log it here to discuss.

Screenshot 2024-08-13 at 15 36 23

Demo: https://community.fsfe.org/t/linqa-a-free-software-bilingual-collaboration-platform-developed-with-public-money/1185

Its Discourse: https://github.com/discourse/discourse

I am also wondering if this is a goal of your project ? It might not be, because the KeyTool seems to want to do sync outside of the OS Sync.

egregors commented 1 month ago

seems to want to do sync outside of the OS Sync.

Ja, exactly. The general goal here is to create an OS-agnostic synchronization system. To be honest, I find the trend toward real syncing of key pairs between devices a bit controversial. For example, like what 1Password or Apple does. It kind of ruins the whole idea of security by keeping keys on the device.

I believe this part should be handled on the server side, where public keys are stored. First, the private key still doesn’t leave the security device. Second, this approach allows us not only to associate several key pairs with one user, but also to provide different permissions for these keys. Just imagine, you have, let’s say, one key just for login and another one for performing more dangerous actions.​

gedw99 commented 1 month ago

seems to want to do sync outside of the OS Sync.

Ja, exactly. The general goal here is to create an OS-agnostic synchronization system. To be honest, I find the trend toward real syncing of key pairs between devices a bit controversial. For example, like what 1Password or Apple does. It kind of ruins the whole idea of security by keeping keys on the device.

I am exactly the same. Dont want to be trapped by the OS to do my Sync - Bundesdatenschutzgesetz (BDSG)

I believe this part should be handled on the server side, where public keys are stored. First, the private key still doesn’t leave the security device. Second, this approach allows us not only to associate several key pairs with one user, but also to provide different permissions for these keys. Just imagine, you have, let’s say, one key just for login and another one for performing more dangerous actions.​

Ok I get it, and are 100% for this too because of data privacy.

Maybe we state these goals in the README at some stage. It will help others to see the objectives and then to have alignment and get on board.

Maybe also add Caddy and Traefik and explain it in the README and Makefile, since we now have these working, so devs can see they can use either.

gedw99 commented 1 month ago

closing because this is OUT OF SCOPE - anti goal :)