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.

> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec

Simple: clients meant for consumers SHALL NOT provide any attestation information. Those fields are intended to be used only by managed devices.

People can be free to use a device that has guard rails for them. The issue is when e.g. my bank forces me to prove I am using a malware device, which is pretty much everything from "big tech". Normies will stay on the normal path anyway and will be using one of those devices, so there shouldn't be a need to block the people who are using something weird, because by definition they are not the average user.

> If anyone in the comments doesn't like the implementation of webauthn, suggest changes to the spec

Rip out resident keys altogether. They aren't needed. You can get 99.9% of the benefits of Passkeys by using non-resident keys - literally the only drawback is that you'd need to enter a username.

Resident keys essentially kill physical tokens. Without resident keys a $10 token can support thousands of websites. With resident keys? A couple dozen, if you're lucky.

Requiring MDM for attestation seems like the extremely-obvious answer to all this, yea.

High(er) security environments exist, and some extremely anti-user features make tons of sense there - anti-user is kinda the point, you don't want people to do anything they like. But those environments should not be allowed to impact any other environments, it's just going to foster abuse. MDM divides them very cleanly.

> Resident keys essentially kill physical tokens.

Can you elaborate? I'm curious. Is there a storage problem?

Again, ya’ll are living in a different world. Passkeys doesn’t have to support your use case, you’ve already got FIDO 2 keys for this. Physical keys have been readily available for over a decade from yubikey and the market penetration for consumers is basically zero.

You missed the rest of that sentence from your quote. It's an open spec, suggest changes to the spec, not me. I didn't write it. I actually agree you should be able to use whatever device you want. I'm a relaying party and I don't require attestation.

There are businesses and their employees trying to influence passkeys to push more towards their business models, because this does shut down a whole avenue of fraud and associated fraud fighting tools that are no longer needed, so there is a boatload of money out there trying to make passkeys worse. Comment on the spec and make your voice heard please.

> With resident keys? A couple dozen, if you're lucky.

Or, future tokens start bundling a bit of flash storage and make this a non-issue. Considering how cheap it is, that ought to be possible even for low-cost tokens.

Ideally you should not be able to determine whether a username is valid without authenticating.

Yes, exactly. Resident keys take up storage space. This article that was updated 5 months ago says that the most recent yubikey can support up to 100 discoverable credentials: https://support.yubico.com/hc/en-us/articles/360013790319-Ho... That might sound like a lot, but given that we want to achieve a migration to passwordless across the internet, you will quickly run out of storage space if every shop on the internet wants a dedicated keypair on your device.

Non-resident keys are so much better, because you won't need to worry about this limitation.

You still need to allocate physical space for 1) the cryptographic circuitry of the token 2) the tamperproof and stress-resistant enclosure. Depending on the form factor, you might not have that much physical space left for storage. The physical requirements for a token are much more complex than a plain USB drive.

> 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.

Where are you still seeing attestation?

Both Apple and (I believe) Google threw theirs out when they moved to synchronizing passkeys, and they’re both widely supported by relying parties.

Other than that, I think it’s fair for e-signature etc. services to be able to require a physical, non-synchronizing credential like a Yubikey. With such a service, it’s not just your (as the key owner), but also others’ security on the line when breaches happen.

I understand your enthusiasm for passkeys and I think there are real benefits, especially for non-technical users. But likewise, there is also enthusiasm for the objectively more secure hardware tokens. Residential keys are a problem for hardware tokens.

So yes, we are living in different worlds. But what we all want is to migrate to more secure authentication methods. And pushing non-residential keys to the wayside just for the convenience of not needing to remember user names feels like a bad trade-off.

So, ruin a thing that works for a few people (and arguably was the primary target of the spec before big tech essentially took it over) for no reason other than marginal relying party convenience?

The only thing needed to preserve their utility would be a minimal rewording (e.g. change “preferred” to “possible” or add a “preferred-if-unlimited-storage” for ResidentKeyRequirement), and a requirement of relying parties to add a username field as a fallback.

The thing you have to factor in is that most people are at risk of phishing or password leaks by compromised sites. The vast majority of users don’t have the problems you mentioned so it’s a question of whether we should leave 90% of users at risk or let them have a safer, easier, faster experience while the remaining people continue doing what they are doing now or drop a few bucks on hardware tokens.

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.

It's not just needing to remember user names, is everyone in this thread just willfully ignoring what I've been saying about needing multiple (privacy incompatible) channels of data to be able to trust these login methods that aren't passkeys?

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.

> everyone in this thread just willfully ignoring what I've been saying about needing multiple (privacy incompatible) channels of data to be able to trust these login methods that aren't passkeys?

I have reread your top post a few times and I think I'm starting to understand your point. To highlight the core part:

> State of the art in industry is basically trying to understand every action that is happening on a device

I wasn't aware that this is happening. And I can understand why fintech companies engage in this invasive practice. However, I never used SMS as a second factor, because I know that it is unsafe. I use hardware tokens, because I care about security. I know that many people do not care about security and it is your job to catch them before they do something stupid. I understand why you like passkeys so much.

But the original point remains: Resident keys are not necessary. Big tech is propagating resident keys. But they could easily use non-resident keys and offer remembering the usernames for the different sites like password managers do it today. It would be an easy win for everyone.

I understand your point, and I’ve thought a lot about that after discussing it here. I actually prefer the resident keys from my side because I can really trust the device is the device, so I don’t need all that data stream about it. That said, I’m going to make sure I support hardware tokens in my system.

My goals are just protecting my user base from fraud and giving them an easy way to login securely. You would probably be shocked at the volume of support calls we get about logging in. It’s 30-40% of the call volume. Easy for a scammer to slip into that stream as well.

That's good to hear. I don't see passkeys anywhere right now because browsers don't have software implementations and my computer isn't capable of a hardware one, which incidentally is part of why I'm not a fan of forcing it on people.

Google’s security key can already support 250 resident keys. I’m not sure how secure it is compared to Yubikeys, but it can’t be that far behind.

Bitwarden has a software implementation that’s been working well for me at least in Firefox. I believe it should work in Chrome as well.