Back

@rmondello “it’s just sparkling secrets”?

@SmartAsABrick Then don’t call it a passkey. :)

@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?

@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.

@fvsch

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.

@uint8 So “If it’s device-bound, it’s not a passkey” is a spicy opinion that does not quite match FIDO’s position (since they recommend the language “device-bound passkey”), but it does match the overall intent and intended primary use case of passkeys.

@fvsch

> 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.

@crh Safe against device loss!

@rmondello Got it, thank you!