AFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly.

Also it seems that Linux is completely out of the picture.

> AFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly.

The Android implementation allowing for multiple third part passkey providers (typically, existing password manager that want to support passkeys) is in beta.

Apple does not pre-announce features, so we are all likely in the dark on their timelines, and whether their timelines extend to infinity.

However, I believe a passkey manager can replace the system implementation via the web extension mechanism in mobile Safari today.

You can use passkeys from a FOSS client on Linux, you can even use your Yubikey if you have one.

just because there are APIs that a FOSS client can call, that doesn't guarantee interoperabiltiy.

> Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration

It is all user terminology for Web Authentication features, so credentials stored on a current Yubikey are also "passkeys".

There are multiple open source security key hardware implementations that support the published specs.

There are multiple password managers that have started to implement "passkey manager" functionality - 1Password and Dashlane have made announcements here and have published code and Web Extensions for desktop.

Android 14 beta has a system API where software providers such as 1Password and Dashlane can work with this system, not just for Chrome but for installed applications.

I doubt Google's Password Manager will ever be open sourced, but it doesn't need to be for an interoperable ecosystem.

Thank you didn't know this! I just hope the underdog can stand a chance against the "it just comes with it"

I do too. The ability for a smaller focused company to innovate and pivot to find unique markets is way different than what the platforms will ever offer. I suspect passkeys provide new ways to innovate beyond what they have been able to do with passwords in the past.

Assuming there is an ecosystem where they can play equally, I suspect they will find all sorts of ways to provide unique value. Their goal shouldn't to be the preferred system across all of Android or iOS, but to offer something a lot of people are willing to pay for.

> but it doesn't need to be for an interoperable ecosystem.

what you described above doesn't guarantee that the ecosystem is interoperable. With passwords, there is no way for the service provider to hide the cleartext password from you, this is inherent to the way passwords work. With passkey, a service provider could decide to hide the private keys from you, effectively locking you into their ecosystem, and there is nothing you could do to avoid this.

I don't know what a service provider is in this case for sure, but I'll assume you mean something like Google Password Manager or iCloud Keychain or 1Password.

There's no guarantee that they will act in a user-beneficial manner, except they all already exist and already act in a user beneficial manner, and that there is no strategic benefit of acting in a user-hostile manner.

> With passwords, there is no way for the service provider to hide the cleartext password from you

Sure there is. They could refuse to do anything but form fill the passwords on registration and authentication pages, where the field in the browser will not allow you to copy the password back out.

The force that keeps them from doing such user-hostile behavior for lock-in today is that nobody would want to use that system. They would not use that vendor. It would be product suicide.

> effectively locking you into their ecosystem, and there is nothing you could do to avoid this.

Unlike passwords, sites are encouraged to allow you to register multiple passkeys. Some sites may push the user to do this for convenience, such as if they see user utilizing a security key or phone to authenticate into their desktop when the desktop is capable of doing passkeys directly.

This gives a whole new ability to jump ship if you decide you don't like your software vendor.

Now, there is a parallel question of "what if a vendor uses their monopolistic power to prevent an ecosystem from being created, and then acts in a user-malicious manner". I suspect they would quickly get multi-national scrutiny.

I just migrated from password to passkey on my iPhone as a Google user. This logged me out of Chome on my Mac computers. Chrome prompted me to login with my Apple passkey, and then generated a new passkey for my Chrome browsers (which will sync between them). I now have access from both Google and Apple ecosystems to my Google account.

WebAuthn is a standard. From what I understood, can use any third-party authenticator like a YubiKey instead of Google's implementation.

That could work for the HN crowd, most people don't know about YubiKey. They will start using Google's implementation and realise too late that they're locked in.

> can use any third-party authenticator

You can, but most people won't because they will be locked-in, this is not the case with passwords as it's quite easy to change password manager without having to reset all your passwords.

The thing with these authentication services is that if Google doesn't like you and blocks your account, you're fucked.

This is not a remote possibility. It happens to thousands of people every day, for entirely frivolous reasons.

Until there is some authentication system that is genuinely robust to corporate control attacks, I'll keep using the imperfect password manager model.