If you can drop a single device in a lake and lose your credential, it’s not a passkey. Passkeys are backed up and synced across your devices to deliver a great and safe user experience, while also eliminating phishing.
If it’s device-bound, it’s not a passkey. :)
@conlan @rmondello
Right now the answer is “same as you do for lost password” which is not very satisfying. The entire #passkeys passwordless revolution depends on still using a password AND MFA if you lose your main credentials.
Although having keys synchronized usually means there is a copy in the cloud somewhere that you can recover, thanks to Apple or #1password or whoever. It’s also not a bad idea to use a competing/separate system to generate a second #passkey for the most important sites in your life (email, bank, etc)
I think in the future there will still be a “one time code” even if passwords are dead and gone. Validate by email, or SMS, or security questions will still be around for my lifetime.
One thing that does show some hope of escaping the “knowing the secret” rat race is security keys like #yubikey. Which right now are not well-known and not well-supported by everyone but are growing.
So there’s a handful of answers to the question but none great.
@rmondello This is a *very* spicy take, and I think it's fair to say it's not shared by everyone.
Saying passkeys *must* be synced only serves to exclude folks that have a legitimate need (or want!) to have a credential that's completely under their own control.
@rmondello I don't think that's helpful for users or developers. You can't tell Webauthn to create a synced credential - you can inspect a credential after it's made to see if it's synced.
So what do you label the UI? "Create a passkey or other Webauthn credential"?
Or do you label it "Create a passkey" and let people make a non-synced credential? Maybe you warn people after you create it that it's not a passkey, even when that's the button they clicked?
I don't really love the FIDO alliance definition, but at least it aligns with what developers can design around.
If the goal is to get people to adopt this stuff (which I think it should be, because passwords are just the worst), then trying to push a definition that doesn't align with how the tech works doesn't help, does it?
@rmondello
I’m going to disagree in the case of hardware keys like #yubikey, which should never leave the device. But you should always have 2 of them for that reason.
Sync is a powerful feature and people should use it. If you have different flavor platforms, creating two passkeys also works fine.
@nekodojo Yubikeys are awesome! Security keys in general are awesome!
But calling what’s on them “passkeys” will confuse average computer users, because the properties of a device-bound key are so different than having keys that are backed up and synced in a password manager.
Call them what they are: security keys. Passkeys are different.
@rmondello
OK I can see your point. Though I can already feel the pressure of vendors wanting to exclude #yubikey from the whole #passkeys push. Making the label not apply to them will accelerate the push to exclude them from the standard and make it acceptable for vendors and web sites to not support them.
Not saying you’re wrong on this, and I think users would be confused either way. I want passkeys to do well. Yubico has been active and supportive of the standard even though they knew they were paving the road that would allow other vendors to steal their market share. If web sites like PayPal decide to support passkeys but not security keys for passwordless login, I’ll be sad.
@rmondello if we’re going to accept that, then someone needs to have a chat with Yubico:
https://www.yubico.com/resources/glossary/what-is-a-passkey/
> The widely accepted passkey definition simply specifies that cryptographic keys are used for login rather than passwords.
I myself tend to agree with this, and I would argue that if you’re trying to make a distinction between different types of passkeys, neither of the derivatives should be called just “passkey.”
@ljrk @rmondello B2B marketing is a whole different animal here, that said...
"also think their [sic] a 2FA"
Both are, assuming the server is correctly set up to require user verification. Or perhaps I'm misunderstanding what you're getting at?
@e3b0c442 @rmondello Yeah, end users may actually be more well-informed here...
Whoops, I shouldn't be typing when tired :D
They're confusing Passkeys for FIDO U2F, that is, still using a password + a YubiKey (wrong #1) for 2FA afterwards (wrong #2).
Using FIDO that way is totally fine, or combining Passkeys with YubiKeys as 2FA or whatnot, but it's not what Passkeys *are*.
@rmondello Is that a normative thing in a standard, or a spicy opinion?
I’m trying to understand what passkeys *are*, and so far I’m puzzled.
https://hachyderm.io/@fvsch/111182221089340118
Reading about passkeys and I’m finding 2 types of info: 1. How to use passkeys in a specific app or platform (what buttons to click and whatnot). 2. High-level descriptions of the public/private keys mechanism. But I’m missing info on the “social” component of passkeys. Things like: - Who generates and stores keys. - What’s the diff between proving you have a key and proving *identity*. - Will services accept any self-generated and self-managed key? Or require one from an identity broker?
The latter. The standards body talks about the definition here https://fidoalliance.org/passkeys.
If that doesn't answer one of your questions lmk.
@uint8 Thanks. Also reading this in their FAQ:
> When delineation is required, passkeys that are synced between user’s devices via a cloud service are generally referred to as “synced passkeys”, and those that never leave a single device (including those on UAF apps) are referred to as “device-bound passkeys”.
@uint8 Though the FIDO passkeys FAQ also suggests that synced passkeys should be the default user experience:
> Syncing is critically important for FIDO to achieve its mission, which is to make sign-in easier and fundamentally safer by replacing passwords in as many places as possible.
> The usability of a password replacement must compete with the convenience of passwords, and one of the primary usability benefits of passwords is that they can be used from any device.
> but it does match the overall intent and intended primary use case of passkeys.
For most consumer users, yes the ability to sync, back up, and restore your #passkeys is a good thing for usability. And it should probably be the default for most/all consumer scenarios.
However, defining "passkeys" to exclude device bound authenticators introduces an ecosystem/UI/UX split for little reason. It's the same technology stack top to bottom outside of the implementation details of the authenticator itself.
We can provide the good default user experience of synced passkeys without taking the freedom from security conscious enterprises/users to use Yubikeys on passkey supported websites.
Doesn’t seem to at the moment, I tried the passkey system out on a VM, and while it’s nice, it’s not as good as the others I’ve tried from either Apple or 1Password.
I would *hope* they build a sync functionality into say the MS Authenticator app for mobiles, it makes the most sense, unless you don’t sign in with your MS account.
@rmondello So you can’t have a passkey if you only have one device.
Can you have a passkey if you don’t own more than one device if the same vendor?
If you own multiple Apple devices, is it still a passkey if Apple locks your account for whatever reason?
Ricky Mondello
Oliver Busch
Jordan
Rick
Conlan Spangler
Thomas Broyer
Nekodojo
Will Smart
Pablo
Gene Thomas 
Sam Gross
Old account
Nick
lj·rk
Jason Broccardo
Tom
Florens Verschelde
Nate Jones 
Micah Benn
CJ
Andrew Kemp
liam
Jørn
Adam ♿