Actually I maybe misspoke and I might go further than that and say that services shouldn't be allowed to make any requirements about how hardware tokens work. This means if someone wants to use a software token that should be supported.

And also I think this is why the passkey standard is bad, it sets rigid hardware requirements and the manufacturers will use this to drive planned obsolescence. If Apple and Microsoft have their way we will throw away $1000+ phones and laptops because someone found an exploit in the TPM that requires physical access.

Yes, that and WEI

"iPhone Keychain" - no thanks, I'll stick with a non-vendor specific provider.

I am trying to escape that awful ecosystem, not dig myself further in.

The option of Yubikeys is fine as long as the basic 1P thing is painlessly usable too.

The "ecosystem" comes as non-several package. Like for instance, my pet issue "if" I'm in the ecosystem, I'd have to give up my headphone jack. And all the rest of it. The "if" is probably most of the problem.

Indeed the jack removal was the first thing that ever made me think of switching. That was a scam.

> I’d have to give up my headphone jack

Not to mention your 3.5” floppy drive!

If jack is floppy drive then Bluetooth is wax cylinder

I don't really have much use for that. Usb drives totally replace them for my use cases.

Do you understand the advantages that headphone jacks have? If not, you could start there.

If you know of a way to export a passkey from iCloud Keychain to a non-Apple device, please do share it!

Otherwise I'd call that lock-in as well.

That's a horrible idea, no different than extracting your ssh private key.

You're asking for Apple to introduce a vulnerability for your convenience.

> no different than extracting your ssh private key.

Which is a thing I regularly do, e.g. every time I switch computers...?

congratulations, you have poor cybersecurity hygiene. it’s still a bad idea.

How else are you supposed to log in from a new device? iCloud is doing that for you anyway, only it requires an Apple device. I can copy ssh privkeys too, and that's fine.

It's easy on a Mac since Safari has a CSV export feature. No such thing on an iPhone.

Have you tried exporting a passkey that way?

Last time I did, I only got passwords out, not passkeys (not that there is an interoperable standard for them anyway).

Oh, I didn't realize passkeys and totp aren't the same thing. Totp secrets go into the CSV. Don't think I even have any passkeys to test with. And supposedly 1Password doesn't let you export either.

This seems bogus. I'd rather simply use a random per-site password; looks like passkeys are the same except non-interoperable.

Bitwarden lets you export them as part of at least their JSON export, but unfortunately there's no specified interoperable format yet, so you can only import them back into Bitwarden (which you can at least self host; you could reimplement their serialization format if you're really determined).

There's some movement in that area in the related FIDO working groups, but I think we'll (by design) never see something like CSV export, and it'll be more like a standardized account migration.

> I'd rather simply use a random per-site password; looks like passkeys are the same except non-interoperable.

They're significantly better than a random per-site password since they can't be compromised on the server side (due to being based on public key cryptography), unlike regular passwords and TOTPs.

I guess the real advantage is, if their server is temporarily compromised, they don't have to make me reset my password to get back in. But it's a per-site password, so the attacker can't use it elsewhere.