If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?

Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is:

* the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform.

* the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options

* the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME

> there isn't even attestation that could allow relying parties to block any specific implementation

This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.

> How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?

> * the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME

This doesn't happen once you disable iCloud Keychain as an autofill option in the device settings in favor of a third-party integration. You could of course argue that it's anticompetitive of Apple to enable their integration by default, but I had to do this exactly once, not every time.

> This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID"

Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.

> the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options

This would be nice from a usability point of view, but it sounds like a nightmare to do securely. I'd be fine with a one-time import/export option, and that's being worked on.

>Yes, but neither Apple (at least for non-MDMed devices) nor Google (for synchronized credentials) provide attestation, so any relying party enforcing attestation implicitly excludes the two largest implementations, making it a non-starter for most use cases.

The discussion was about passkeys as a standard, so "well right now Google and Ape happen not to use this part of it" doesn't really change that. It could change tomorrow for all we know and there'd be nothing to be done about it.

By the people on HN who stay away from passkeys, this is one of the most commonly named reasons.

> It's really as open an ecosystem as it gets at this point

However, they fumbled the introduction by trying the “maximum vendor lock” approach first. Now they need to convince everyone otherwise, even if technically it’s open now.

I also wish they'd have started off like that from the beginning.

It might have taken them a bit longer to get the initial implementation out the door, but it would have avoided all of these discussions, which I'm certain are also impacting WebAuthN/passkey adoption across the web (assuming that the views on passkeys here are at least somewhat representative of technical decisionmakers).

But if the choice is between getting to the status quo via suboptimal intermediate steps or not having WebAuthN and passkeys at all, the former seems much preferable.

I disagree somewhat that that is a "fumble" so much as a symptom of what was necessary to get mainstream acceptance, what a lot of us on HN see as "maximum vendor lock" is also an attempt at building a "pit of success" for average, "boring" users. An "Uncle Charlie" with an iPhone, an iPad, and a Mac that trusts Apple and was already using iCloud Keychain as their primary password manager is going to have an easy time with passkeys and is going to have a harder time accidentally enrolling a passkey they don't understand or know how to use the next time or next device they login from. That's a reasonable "pit of success" for an average, "boring" user.

There's a lot of users that isn't great for. Especially there are statistically a lot of iOS users that use Windows desktop/laptops that Microsoft and Apple are trying to bridge but don't always have the best UX today. Same for Android and Windows users, there's statistically even more of those.

Also, as you can tell from HN comments every time Passkeys come up, HN is full of anecdotes of the craziest mixed device ecosystems people can build. We can be a loud set of users, and we certainly need the most convincing that our "power user" needs are met for all of our complexity requirements.

I largely agree, except for this:

> anecdotes of the craziest mixed device ecosystems people can build

All it takes is for somebody to use both an iPad and an Android phone. iPads are relatively cheap (cheaper than many Windows laptops!); iPhones are quite expensive. That's a lot of users right there, and I think it must be at least as common as Windows + iOS users.

Right. That is not what I meant by "craziest mixed device ecosystems", and yes, I agree that Android + iPad is a common enough situation that needs good defaults that we haven't yet entirely solved for (but there are options today and hopefully it will get better). Windows "knows" it has to be a bridge device with whatever the user's phone ecosystem is, iPadOS today mostly assumes the user's phone "must be" an iPhone. From Apple's perspective that still makes sense as a useful "default" for what they consider to be their average user.

> No, this "ideal state" is in fact the reality I've been experiencing for the past few months.

I agree that technically, it seems possible to choose between hardware keys and OS passkey. But I also agree with the article that they try to push their own solution by hiding the alternatives, and that should not be allowed.