Closed Kieun closed 11 months ago
I think the issue here is that I rely solely on the credProps
extension to determine if a credential is discoverable or not when it's created. I don't think Android supports it yet, so because I don't get anything back that flag ends up getting set to false when I save the credential.
I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.
The way of our Webauthn server implementation determines whether the credential is discoverable or not is as follows.
So, our server implementation's credential type regarding the discoverability has tri-value (discoverable, non-discoverable, unknown). This is reasonable and safe way of determining of discoverability of the credential.
I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.
I'm not sure this is safe assumption. Maybe, later, non-discoverable credential (such as U2F, FIDO2 roaming authenticator) might provide backup feature. In this case, the backup targets for those authenticators are the wrapping key. So, the wrapping key moves around (import/export and even backup) across devices.
I think the issue here is that I rely solely on the
credProps
extension to determine if a credential is discoverable or not when it's created. I don't think Android supports it yet, so because I don't get anything back that flag ends up getting set to false when I save the credential.I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.
Is there any update on this one yet (or in general on more devices e.g. iOS or macOS), where the demo also states "Non-discoverable credential" due to the empty credProps
extension)?
@Kieun @vincentdelitz I just updated webauthn.io with some updated credential labeling:
Top: iCloud Keychain passkey, 1Password extension passkey Bottom: macOS Chrome passkey, U2F security key
I'm going to consider this issue finally closed. Let me know what you think, and open a new issue if you think it needs tweaks.
Thanks @MasterKale. I think that's now a good description that helps to better understand the different type of keys. Based on your updated implementation and the scheme provided by @Kieun above, we did a quick test here on some authenticators to check the behavior.
Great help is also this article, that our test above is built on (extends the table basically).
Although the credential is discoverable passkey (backup enabled), the authentication success page does not properly show the credential info.
I just try to CDA with Android passkey and macOS with empty allow list and it works well except the credential information is not matched one that I created before.
Expected credential type: discoverable multi-device credential Current credential type: non-discoverable passkey