4 ms·

That's the point, if I'm reading this thread correctly. Google/Apple/Microsoft's implementation will be going out of their way to tie it specifically to a devic

That's the point, if I'm reading this thread correctly. Google/Apple/Microsoft's implementation will be going out of their way to tie it specifically to a device and biometrics.

lxgr 3y ago
In fact, Google and Apple have recently started synchronizing Passkeys to the user‘s cloud account, which effectively undoes any specific device binding. As a Relying Party, you can’t know what authentication method will be used for either enrolling a new device, or on the new device itself.
afavour 3y ago
Isn’t tying specifically to a device and biometrics the point?
- josteink 3y ago
  No. The point is replacing passwords with something which is equally user-friendly, but which cannot be phished. Ie replacing passwords with cryptographic keys tied to a specific website. That is, your passkey for amazon.com won’t work on a phishers site amozon.com or lookalike.somehost.org. And in the hypothetical case of your passkey for site X being leaked it will never be the same as for site Y, so it’s not reusable. No part of the specification requires Google, cloud or third party trust. Those are just “user-friendly” client-side implementations.
  - danShumway 3y ago
    > which is equally user-friendly, but which cannot be phished. This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.
  - 0xCMP 3y ago
    > No part of the specification requires Google, cloud or third party trust. AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth. > The point is replacing passwords with something which is equally user-friendly, but which cannot be phished. Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.
ezfe 3y ago
Yes, Google/Apple/Microsoft are likely to tie it to device biometrics, but: - 1Password is rolling out Passkey support next month - Apple is on the record stating that passkey import/export is on the roadmap You can already use the 1Password demo and export the passkey it generates and see the raw data.
- prophesi 3y ago
  Glad to hear Apple's allowing import/export. The issue I was thinking of is setting up passkeys for your phone and now you can't use it on desktop, or switching to Android/iOS and it can't carry over.

That's the point, if I'm reading this thread correctly. Google/Apple/Microsoft's implementation will be going out of their way to tie it specifically to a device and biometrics.

lxgr 3y ago

In fact, Google and Apple have recently started synchronizing Passkeys to the user‘s cloud account, which effectively undoes any specific device binding. As a Relying Party, you can’t know what authentication method will be used for either enrolling a new device, or on the new device itself.

afavour 3y ago

Isn’t tying specifically to a device and biometrics the point?

josteink 3y ago
No. The point is replacing passwords with something which is equally user-friendly, but which cannot be phished. Ie replacing passwords with cryptographic keys tied to a specific website. That is, your passkey for amazon.com won’t work on a phishers site amozon.com or lookalike.somehost.org. And in the hypothetical case of your passkey for site X being leaked it will never be the same as for site Y, so it’s not reusable. No part of the specification requires Google, cloud or third party trust. Those are just “user-friendly” client-side implementations.
- danShumway 3y ago
  > which is equally user-friendly, but which cannot be phished. This is good to bring up. Without vendor lock-in and attestation, passkeys have huge benefits for blocking phishing attacks. It's not "stick with passwords" or "deal with lock-in", it's possible to get rid of the current problems and still end up with a system that's way more secure than traditional passwords.
- 0xCMP 3y ago
  > No part of the specification requires Google, cloud or third party trust. AFAIK the only reason you need Google, Apple, or etc. is because the mobile OS needs to make the process of doing the bluetooth pairing between a random device and the phone seamless. Given the crap networking we have in the world you need a 3rd party everyone can reach to exchange the most basic information. Then everything is local via Bluetooth. > The point is replacing passwords with something which is equally user-friendly, but which cannot be phished. Yes, and biometrics (which pretty much everyone uses) are great! They're device ONLY. It's entirely a convenience feature that avoids needing to enter the Required To Setup PIN/Passphrase every time.

ezfe 3y ago

Yes, Google/Apple/Microsoft are likely to tie it to device biometrics, but: - 1Password is rolling out Passkey support next month - Apple is on the record stating that passkey import/export is on the roadmap You can already use the 1Password demo and export the passkey it generates and see the raw data.

prophesi 3y ago
Glad to hear Apple's allowing import/export. The issue I was thinking of is setting up passkeys for your phone and now you can't use it on desktop, or switching to Android/iOS and it can't carry over.