3 ms·

can someone who understands the cryptographic basis explain how centralized this is? it sounds like an app can consume passkey logins without registering with

can someone who understands the cryptographic basis explain how centralized this is? it sounds like an app can consume passkey logins without registering with a provider? do providers phone home when I log in? can providers block an app from using them? can I self-host a provider, or is there a shortlist of approved providers? is there any provider that allows me to backup private key without sending it to their cloud? is it similar to openid in that it shares email etc with the app on login?

cma 3y ago
It will really be a shame if we got ssh-like public key authentication for the web, but can't self-host it.
- deleted 3y ago
  [deleted]
kdbg 3y ago
First, just a high-level overview over how it would work as an app/consumer which is not terribly centralized outside of requiring browser support: Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store. For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed. --- So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it. So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.

cma 3y ago

It will really be a shame if we got ssh-like public key authentication for the web, but can't self-host it.

deleted 3y ago
[deleted]

kdbg 3y ago

First, just a high-level overview over how it would work as an app/consumer which is not terribly centralized outside of requiring browser support: Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store. For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed. --- So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it. So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.