| HN Mirror

Arguably that "first step" was BrowserID/Mozilla Persona which "failed" for interesting reasons, including the team was retasked by Mozilla for the failed Firefox OS and Persona never got good "engagement" on the wild internet and there was never a larger coalition around it as a standard.

For better and worse, the needs for biometric/2-factor/TOTP were the "trojan horse" to build better web auth standards that were cross-platform/cross-browser "coalition worthy". FIDO's WebAuthn has accomplished a lot that BrowserID failed to manage. The "mixed up other muck" is the reason that Passkeys even exist in the first place and the hope that they can accomplish what Mozilla once failed to do. Passkeys is just a "brand name" for using WebAuthn to try to kill passwords; all the other muck was already there before the brand name.

> Seems to me that the standard should simply allow someone to delegate their "passkey keeper" of choice to be the authentication engine that tracks tokens. It can be up to the user (up to their passkey tool) to decide everything else. But set up a system that let's us log in without a password, and without a proprietary auth system like google or facebook etc.

This is where the technology is going, it's just unfortunately never as easy as you would think "simply allow" to ever be. Passkeys aren't a proprietary auth system: they are built on WebAuthn standards, anyone can implement them (and many are). (WebAuthn itself isn't prone to some of the same centralizing effects of OpenID Connect either, Google and Facebook's logins being also built on "standards". WebAuthn is the standards that lit up cross-platform/cross-vendor multi-factor on the web in the first place. Passkeys just replace/drop factors.)

It should be up to users to pick the "passkey manager" they want to use. These are already many of the same choices users have for "password managers". (Apple iCloud Keychain, Android Password Manager, Windows Credential Manager, 1Password, BitWarden, Mozilla Firefox Sync, and more already support Passkeys and more implementations are expected to come.) On iOS (and iPadOS and macOS) the UIs for selecting your preferred "passkey manager" mirror and look almost exactly like the UIs for selecting your preferred "password manager". Those UIs were slow to arrive, as Apple rushed to get any Passkey support out the door as soon as they could, so a lot of people got the wrong impression in the early days of Passkeys, but those UIs exist now in most recent iOS versions. It's expected similar UIs will show up for Android and Windows (and various browsers) sooner or later.

There are also standards in progress for better key sharing between "passkey managers". Microsoft has been part of the champions group for that effort (stuck in the middle between iOS and Android more often than not for a lot of average users), but tools like 1Password and BitWarden would also be hopeful for greater compatibility for "import/export/share/sync" of keys between providers. I know a lot of people don't think passkeys will be ready for their preferred use cases until such standards are further along. In the meantime though, you can try to choose a personal lowest-common-denominator platform. (The iCloud Control Panel on Windows has limited Passkeys support for Chrome-based browsers if you need cross-platform reach from Apple's ecosystem, right now, for instance. Also, there is a WebAuthn backed QR Code-flow based Bluetooth LTE-based standard for delegating keys to devices like phones.)

It also is up to the user and their "passkey manager" a lot of the details of passkeys: key sync, key recovery, key types, multi-factor requirements. All of those currently vary across implementations, and there are ways we can likely expect them to always vary on details. (Apple's choices are based on what they were already doing with iCloud Keychain; those differ from Microsoft and Google's approaches, including a larger focus on E2E encryption. Apple disagrees with Microsoft and Google on "key attestation" that certifies specific keys come from specific hardware enclaves, which can be used to verify that certain biometrics and multi-factor options were already applied to the key before usage and also corporate "requirements" like device management, but also have privacy implications and recovery complications.)

Picking a "passkey manager" is a little more complicated than picking a password manager because there are more standards that need to be interoperated with, and many APIs are always going to be platform-specific and sometimes browser-specific (whereas worst case password managers can often route around things and at least fallback to nearly universal copy and paste APIs or keyboard "typing" automation). But "passkey managers" in the end should feel very similar to password managers for end users, including that most average users are likely to just use whatever the default is in their phone OS of choice (so most eyes are on Apple and Google to get these early transition days right).