upvote
> Linux is the only oddball here, I had issues getting this flow to work.

Take a guess why.

Passkeys are just a trick for vendor lock-in disguised as a security practice.

reply
They are, however, completely unphishable, which is a big plus IMHO
reply
Firefox just didn't support it cleanly, I think Chrome did, I don't remember. Apparently it's just due to Linux not having a native passkey implementation. Dang.

Edit:

Apparently BitWarden should work, but my particular passkey was not on there.

reply
> Apparently it's just due to Linux not having a native passkey implementation.

Excuse me? The infrastructure for "an apps is trying to login with a private/public key pair, and right now it needs the private key to encrypt some part of the transaction" has existed on Linux since it began.

The problem, as best as I can understand it, is that some/all browsers are not treating passkeys as an extension of the key system that began with ssh(1), even though technically speaking, they are.

reply
I use Bitwarden on Linux. There is no option to do anything with a passkey I have stored there except delete it.
reply
Unpopular opinion but correct the whole thing has been designed to lock you to devices they make and have themselves be the arbiter of your authentication.

If that wasn't the intent they could have make the thing work like ssh keys, encrypted at rest, you can take them wherever you want.

reply
I don't think that's the unpopular opinion, I think that's the standard opinion, outside of the corporate security cloister.
reply
It is not Apple's job to implement Passkey into Linux, that is up to the Linux community to build up and figure out, and then for Firefox to implement it on Linux. On the other hand, Chrome just works with it, so maybe Firefox either implements it for Linux in-house, or figures out an existing initiative they could invest resources towards and help to prop up so they can integrate against it on Linux.
reply
My issue is not the lack of Linux support, my issue is the dependence on hardware components, that are distributed by a small group of incumbents, that is pretty much baked into the spec.

What they want is to lock your identity to your android and/or iphone devices.

reply
What are you talking about? I can literally export all that data to another OS or password manager. Takes a whopping single click.
reply
Only to other proprietary systems within the FIDO Alliance that you don't own or control.

Additionally passkeys allow services to detect and ban specific password managers, so have fun when the only approved managers that works consistently across all services are Google/Apple/Microsoft. There is already a list of "bad" clients here https://passkeys.dev/docs/reference/known-issues/

reply
Again, what are you taking about? There are open source implementations available. I can write my own. They do work. This list just shows some which do not actually implement the spec correctly.

Also moving the goalpost. The post I replied to said I couldn’t export it. I absolutely can, and have, with a single click. To another provider. It’s really not a big deal.

reply
I didn't realize this was supported, I'm kind of favoring Apple's Passwords app since you can lockdown your account and they are very on top of someone accessing anything of yours. Any time I power on an iPad I havent used for months they tell me a new device can read my texts type of thing, which is a nice paper trail.
reply
I wouldn't favor an application that is locked to a big player account (Microsoft, Apple, Google) where a ToS violation for something unrelated may lock you out of all services, passwords/keys included.
reply
Yes me too. And it works great. I do make a backup of it to another provider once in a while though, just in case.
reply
Also note this from the spec:

> A Public Key Credential Source’s generating authenticator determines at creation time whether the public key credential source is allowed to be backed up. Backup eligibility is signaled in authenticator data’s flags along with the current backup state. Backup eligibility is a credential property and is permanent for a given public key credential source. A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.

* https://www.w3.org/TR/webauthn-3/#backup-eligible

reply
reply