4 ms·

If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey")

If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is: * the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform. * the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME > there isn't even attestation that could allow relying parties to block any specific implementation This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.

lxgr 2y ago
> How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? > * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time. > This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. > the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.
- maeil 2y ago
  >Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it. By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.

lxgr 2y ago

> How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key? > * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time. > This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. > the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.

maeil 2y ago
>Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases. The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it. By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.