Passage Is Joining 1Password
passage.id
passage.id
Even though Apple (and likely a couple more) will provide their proprietary passwordless system with cloud sync, a lot of people don't want to rely on an iCloud account to be your backup in case you lose your phone. Which means that cross platform password managers are in an excellent position to compete in passwordless, since it can span all your devices and browsers. They are already keeping sensitive secrets, integrate with biometrics and device-specific soft-locks, audit logs etc – all they need to do is add some integrations for WebAuthn and certain platform APIs that Apple and friends have to provide.
The main adoption-risk with password-less is fallback for when the user's browser isn't fully integrated with a pw-manager. Not that it's impossible, but if you need a backup you now have a multimodal and more complicated system, and if that burden is shifted to individual web/app developers it will certainly delay or even stop the transition.
This is the big one for me. The user story for logging in to a site on Windows with an iOS passkey is to scan a QR code with your phone, which sounds obnoxious.
I'd rather just have 1Password be the private key repository and those keys will sync to Mac/Windows/Phones through it instead of them being locked into iCloud Keychain, and it can handle logins just like normal.
I like Bitwarden more personally, but if the important aspects are standardized it shouldn't really make a difference.
The calendar is another good example: adequate for many people, but trivially supplanted by a third party app (I use busycal) that apple treats as first class.
I've found this flow rather acceptable actually. I usually use it for Discord/Steam.
I’d rather Windows Hello maintain a BLE connection itself and implement this (or the password manager suggestion).
The concept is that many people will frequently have multiple passkeys, thus not be 'locked in' to any one sync ecosystem.
From https://github.com/w3c/webauthn/wiki/Explainer:-broadening-t...
> When signing in on a different computer, either the credential will already be locally present (if the computer is using the same sync fabric as the phone) and suggested by autocomplete, or else the user’s phone can be used to transmit the assertion to the computer. In the latter case, the service may invite the user to enroll a local platform authenticator for easier sign-in in the future. (Now the newly registered credential may be part of a different sync fabric, and thus enable local sign-in on other devices.)
We'll see how things play out.
With that being said, we (or someone else) may reintroduce magic links as another login alternative of Hanko though, because we also think that it is a better UX to click a link than to type a code.
In any case, our take is that the importance of the fallback auth method will diminish over time due to the omnipresence of passkey support.
Wordlists are a good solution too, as you say.
Assuming you're using universal app links, if they open it on a device with the app installed, it'll go straight there. If not, it'll show the QR code and the user can just scan that with their default camera app on the device they're trying to use.
1Password moving into the developer space?
Maybe a physical notebook. Still infinity better than increasing your threat surface by a third party holding a bunch of keys that might be encrypted well.
Let's try it this way. I'll use a third party if they indemnify me. You screw up, you pay me?