I think this is exactly the "Passkeys are a trap" argument though right? If you lock yourself into a single vendor, everything is easy and beautiful. If you choose a diverse set of vendors, it sucks so much more than passwords and password managers ever did.
That wasn't FIDO as a group. That was one vocal member and even their employer ended up disowning the comment. It also wasn't about sync, it was about plaintext export.
The fact that they are reserving the right to say what software I can export my keys to makes every rumor a real-burguer. Even if this one specific case turns out to not be real.
"They". Again, it was one guy, who didn't have the full backing of his employer much "the FIDO group". Who made a suggestion, though it was written as a threat because he was bad at communication.
Not to mention the only way to blacklist a specific app from Passkeys is to use the AAGUID from attestation which means it only applies to attestation. A few pieces of software were providing AAGUIDs by choice even when not attested and Apple helped remind them that the spec says non-attested Passkeys should always just return an Empty UUID (all zeroes) in AAGUID. The people that are going to block non-attested Passkeys might as well block all of them, including Apple consumer Passkeys.
This is not accurate. The very first sentence of that issue is:
> Passkeys should never be allowed to be exported in clear text.
and from another comment by the issue creator:
> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.
They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.
Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.
The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.
Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".
Well, KeePass is self-hosted, and I hadn't heard of strongbox before, but it says on the website:
> Store your data anywhere you like, online or offline. Sync with every major cloud storage provider or your own server over WebDAV or SFTP. Use your Strongbox database with any KeePass compatible client on any platform.
Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.
The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.
So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.
The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.
Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.
I'm not saying it's impossible, I'm saying there's a barrier that's useful to further vendor lock in. My mom is going to use Apple passwords on her iPhone. When she needs a new phone, the complexity of import/export and fear of losing access to her accounts is going to push her to buying another iPhone. It's just another avenue of lock in, like existing OS level password managers, just with an extra level of confusion for the end user.
My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."
The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.
Mostly, though, it is not true lock-in, as in they mostly don't force you to do things their way. They encourage it, make the features pretty seamless to use, etc, so that you want to stay in their system, but they generally permit you to use whatever tools you want.
The fact that the password manager someone might use on another system is a complete piece of crap does not mean passkeys are an Apple lock-in attempt.
There are an open standard. You just have terrible software.
My issue isn't with the standard, but if all implementations lead to the same shitty experience of 3 different apps begging to store and use my passkeys, then something isn't working right. In my case, the terrible software is Apple's Mac OS, Google's Chrome and/or Firefox, and sometimes Bitwarden still acting weird. Lets not even get into how wild Windows acts when a passkey shows up.
Saying it's an open standard, and that it's just all the major players I'm forced to interact with that make it suck isn't very helpful. That's like the people that say "Don't like iOS? Build your own successful mobile OS lol"
I’m sorry you have multiple pieces of software that want to be in charge, but aren’t passwords the same? Because Chrome and Firefox both want me to use them for my passwords. It’s not a problem unique to Passkeys.
It’s just everyone ignoring user preferences to try to score stickiness.
As the previous article says, some passkeys are open, while others require lock-in, and megacorporations deliberately create confusion between the two.
