Close - it is a signing key, e.g. used for integrity and authentication
> To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
This is how non-discoverable WebAuthn credentials (may) work, and is based on the U2F model. These hardware security key fobs did not have sufficient memory to store created credentials and associated metadata for potentially hundreds of sites. So instead, when you registered a credential it would generate a handle, and that handle would be returned to the site. To request authentication, you had to provide a handle which the authenticator understood. Such a model is really meant for second-factor authentication, e.g. after we partially authenticate the user with a knowledge factor, see if they have the physical factor.
A passkey in contrast is meant to indicate a discoverable credential. You don't need to provide those handles to authenticate. Instead, example.com shouts into the void (of browser javascript API) that it would love a previously registered credential. It hasn't authenticated the user at all, so it has no idea which credential that might be. An authentication response includes the handle and a signature, such that it can be correlated with the existing registration on a user account.
Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
I think you're right about discoverability being a key property differentiating Passkeys from WebAuthn credentials, I got that one wrong. I think the other ones would be it's likely syncable across devices, and likely requires some type of user verification.
You're probably right that if an authenticator is supporting discoverability it no longer makes sense to store the encrypted private key with the RP. It's still allowable though[0].
> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)
> I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected.
The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations).
Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer).
Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security.
But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery.
The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration.
> I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys
Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine.
Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.
Close - it is a signing key, e.g. used for integrity and authentication
> To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
This is how non-discoverable WebAuthn credentials (may) work, and is based on the U2F model. These hardware security key fobs did not have sufficient memory to store created credentials and associated metadata for potentially hundreds of sites. So instead, when you registered a credential it would generate a handle, and that handle would be returned to the site. To request authentication, you had to provide a handle which the authenticator understood. Such a model is really meant for second-factor authentication, e.g. after we partially authenticate the user with a knowledge factor, see if they have the physical factor.
A passkey in contrast is meant to indicate a discoverable credential. You don't need to provide those handles to authenticate. Instead, example.com shouts into the void (of browser javascript API) that it would love a previously registered credential. It hasn't authenticated the user at all, so it has no idea which credential that might be. An authentication response includes the handle and a signature, such that it can be correlated with the existing registration on a user account.
Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.