Firstyear
commented
10 months ago @flarocca They're relying on discoverable/resident keys. This forces devices to consume space on the device to achieve these. This way the credential itself stores a uuid inside the memory of the device along with the key so it can be "discovered".
We specifically have these feature gated today because using this feature can "soft-brick" security keys as many models can't manage or delete rk's once created, and they have finite space. See https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/
We support opportunistic use of discoverable credentials if the authenticator makes them - however, only iOS does this today, and this is only activated through conditional UI. It's likely we will expose this as a feature next release. Conditional UI on chrome however, is another topic being a very confusing and poor experience in general - we might even consider not exposing condui just because of how bad chrome's ui's are for it.
We will never force resident keys to emulate the github workflow. We actually oppose it, have fed that back to github and they rejected the input. In their "passkey" adoption threads, multiple reports already exist of users who have filled their security keys and can no longer use them due to githubs choice. Similar reports already exist for Azure, which has forced people back to less-secure authentication mechanisms.
This is the opposite to what we want - we want all people to be able to use their choice of authenticator, without penalty.
It's also worth noting that by github forcing rk, I believe android will only allow google password manager and not security keys, see:
https://github.com/kanidm/webauthn-rs/issues/365#issuecomment-1756605203
Generally, our view in this project is "the whole space is quickly becoming a complete mess", with conflicting requirements, that overlap in ways that can cause other devices to stop working. There is no longer a clear, simple way for us to offer webauthn/passkeys to devices that "just works" while respecting users choices.
Hi! This is not an issue, but rather an implementation detail question. The API does require, in registration as well as in authentication, the generation of a unique user id. In the example, the FE ask for a email that the BE uses to lookup into the DB and get the user_id (in the registration flow it creates a new user_id). That makes sense.
However, If you look at how Github passkey login works, Github does not require me to enter anything, but somehow when Github makes the request to the WebAuthN API it knows there was a passkey registered in my device for Github (it uses my username as the display name).
I am curious about how it is implemented without asking the user for some unique factor (such as the email).
Thanks