Including explanation for "resident-key-support" feature in crate.io page

[junekimdev]

I found brief explanation of features in /webauthn-rs/src/lib.rs for this crate, which I think awesome.

However, I couldn't find explanation about resident-key-support feature in /webauthn-rs/src/lib.rs.

Would including explanation about resident-key-support feature in /webauthn-rs/src/lib.rs be a great idea?

[Firstyear]

For the moment we have been specifically avoiding actually documenting this feature because we aren't sure if we should keep it or not. If we do it will likely be for USB security keys only and with strict attestation applied.

The major issue is that most vendors like Google and Microsoft are incorrectly pushing resident-key required, but security keys like yubikeys have extremely limited rk storage. By pushing rk as a default, these keys can end up filling that storage and unable to delete any keys at all. This has already affected a number of people in the github passkey rollout, and with AzureAD/Entra ID - these users can no longer use their security keys at all. Additionally both vendors have blocked changes that would make securitykeys avoid rk's in the majority of cases.

This is also to say nothing of the issues we have found with Android and it's broken handling of credentials.

So because of this, we don't want to advertise features like this, where people could go "oh I saw this on googles docs, I need to enable that" when the end result becomes "actually damaging and bricking peoples devices".

Our goal has always and will always be to make webauthn as accessible and safe as possible, and until the situation changes, resident-keys have negative impacts on that.

Now if your goal is to pursue conditional UI, we also don't enable this by default because it's broken on pretty much every browser today. Again, our goal is to make webauthn the best possible, and conditional UI today doesn't meet those standards. I have this documented extensively here: https://github.com/kanidm/kanidm/issues/1542#issuecomment-1509446660 We have done some user testing and generally the feedback from conditional UI is that it's "confusing and hard to use".

I hope that helps explain this. Again, please note this feature flag is likely to go away in future, and only attested usb devices will be eligible to operate with resident keys if we choose otherwise (iOS and Android do not provide attestations of sufficient quality to allow them in these situations).

As a more general observation, a lot of these "fancy features" that have been getting piled into webauthn generally make the experience harder and more confusing to use, rather than easier or more accessible.

[junekimdev]

• While I think Resident Key (or Discoverable Credential) is a crucial feature, I agree that it needs more supporting tech to emerge to increase acceptance rate e.g. Resident Key Manager.
• I was just curious about the feature this crate has to offer; but, couldn't find any explanation. @Firstyear's answer is good enough to meet my curiosity.
• Still, explicit comments with little bit of warning will be more helpful for those who want to venture around with knowing the risk they have to own.

😸 Thx!

[Firstyear]

• While I think Resident Key (or Discoverable Credential) is a crucial feature, I agree that it needs more supporting tech to emerge to increase acceptance rate e.g. Resident Key Manager.

This isn't really the issue. The issue is all the authentication flows that rely on rk like conditional ui are awful. But the vendors pushing rk ship those ui's because they prioritise platform lockin rather than good experience.