There are already different specs for hardware tokens, if there was adoption by consumers people like me would support them, but there isn’t. Hell I was an early yubikey user as a consumer myself, but the utility was never there because there was so little adoption by regular people.
You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point.
So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see.
>Using anything other than chrome or safari
These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs.
>using iOS and Android without a 3rd party password manager
Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept)
I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer.
Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed
> Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed
Absolutely! But on the other hand, let’s not stop at good either if there is a path to something that works for everybody. I do think there is one here!
> I don’t understand what changes _you_ would like to see.
Largely three things:
- Bring back device-local keys with attestation. (Less of a spec issue than an implementation one.) Unexportable hardware keys had value for various contexts like payments, where “delegation” to a third party provider has a specific legal/regulatory meaning and might be a dealbreaker; passkeys kind of made enforcing that impossible (and so they don’t get used by many banks, for example).
- Add an option to “entangle” multiple hardware authenticators securely, such as a pair of Yubikeys sharing a root secret and supporting only non-resident credentials. I could put one in my safe, friend’s house etc. and enroll it into new services without constantly needing access to it. (This one also seems doable without spec chances, but would presumably be much safer with them.)
This one would solve the biggest availability obstacle I’ve seen people mention here and experienced myself to using hardware authenticators, driving people (including myself!) to cloud-syncing software authenticators instead.
- Cement key exportability and an open private key storage format in the standard much more than it currently is. Put it behind a lot of glass (or users will get scammed out of their private keys), but do let me break that glass if I decide to.
I'm with you on device local keys with attestation.
entangling multiple hardware authenticators... I'm trying to imagine what this looks like from the implementation side. Are you thinking of something like Shamir's secret sharing being built into the hardware tokens? Because from my side, I send you a challenge and you respond, I don't really care how your system is setup.
Key exportability is basically where I get off the bus. I don't care what kind of glass this is under, people are going to get tricked into doing it and then it will undermine the whole system. I'll have to go back to trying to discover everything I can about the device and if it's been compromised, hell the caller with the key is going to look far more legitimate to my systems than the actual customer.
You’re 100% right that the experience isn’t seamless yet for people outside of apple’s ecosystem or google’s but this is just catching hold, and the spec isn’t complete, this original article demonstrates a real improvement that should fix a pain point.
So, I do appreciate the way you’re engaging on each point, but I don’t understand what changes _you_ would like to see.
>Using anything other than chrome or safari These will improve as support improves, I see failures and then have to deal with support calls when the user is on something that isn’t supported well. I don’t check user agent, but it would cut down on my support costs.
>using iOS and Android without a 3rd party password manager
Ok, I understand the problem here, and I think I understand the issue with passkeys not being savable like a ssh key, because the apple and android ecosystem is using its keychain and syncing that keychain with its respective cloud service, you can’t use the same passkey on both systems… but the restriction here saves the users from losing these digital keys or having them stolen, and saves me as someone trying to protect their money from basically having to make a passkey need enough secondary data about your device and other factors. I think you’re missing what I posted about for 2 factor… to support it right now for anything other hardware keys (which are basically only supported in volume by a different central authority, like the IT dept)
I need a huge data vacuum operation on the backend to know who you are, where you are, what device you’re using, what that device has been doing recently, if you’ve swapped your sim, etc etc etc. as a counter, you can just make a passkey on the iOS and the android ecosystem, and now you’re good. Extend this to any other ecosystem you want. Yubico has an author on the spec, they aren’t ignoring the use of hardware keys. I’m sure you would be happy to not participate in that data vacuuming operation, and while it’s dual use (marketing and fraud prevention) they still have a veneer of use for the consumer.
Perfect is the enemy of good in this case. Let’s help all these regular people not get scammed