FIDO Alliance publishes new spec to let users move passkeys across providers

In one of the things that I do in my job, I run the auth system for a fintech, and passkeys are an incredible step forward for the typical user. Being able to migrate your passkeys between providers is a great step forward, I'm glad this is being implemented.

Lots of complaints about passkeys and "big tech paternalism" in the comments here, and frankly I don't think ya'll deal with the middle of the bell curve user base that much.

I've got users who, by literally no fault of their own, are being social engineered into reading back their SMS OTP codes to fake tech support. State of the art in industry is basically trying to understand every action that is happening on a device (via mobile phone network providers, location, their actions across multiple other sites, etc. etc. through vendors providing this type of intelligence... by vacuuming up all your data) to understand if fraud is happening by seeing if you can even trust the device that is getting the SMS. Every time we make a step forward in privacy, this gets harder and harder (fingerprinting devices is basically pointless now, so how do I tell if this should be a trusted device or not) so there is a driving force against improving user privacy coming from these vendors.

Passkeys are the first positive step in auth I've seen in a decade that the average user will pickup and use, it helps them login and helps them not try to set a weak password they shared with multiple sites, and they can't read it back to a scammer who is fake tech support.

Would I like passkeys to be more like ssh keys? um, maybe but I don't care about it one bit in practice. I use passkeys for everything I can and I've never once seen friction. The average user does not want to deal with backing up their passkeys or even thinking about them, heck most of them don't. If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.

> I use passkeys for everything I can and I've never once seen friction.

That’s great for you, but they don’t currently work like that for anyone

- using anything other than Chrome or Safari (many sites perform broken user agent based support detection)

- using both iOS and Android (at least not without setting up a third-party password manager, which not everybody knows how to do, or even why)

- not using iCloud (iOS just outright refuses to store local-only credentials, last time I checked at least)

Passkeys are absolutely an improvement for anyone able to use them, but that’s still strictly less users that can use passwords. And even for those that can use them, the availability story is still worse (almost by design, but that’s no consolation for a locked-out user).

> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec and do the work to get it implemented instead of complaining about it in the comments.

I have, with no success. There seems to be a misalignment of priorities and incentives. I even understand where the editors are coming from, but like most industry-sponsored specs, it’s really not the democracy you’re trying to paint it as.

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.