Android Passkey support affecting Yubikey UX

[hwhmeikle]

Firstly, thank you for all your work on this repo. It's made implementing webauthn so much easier. I'm hoping you can help me get over this obstacle:

I updated my app to support passkeys by following this guide:
https://simplewebauthn.dev/docs/advanced/passkeys/.

However i've noticed that this affects the authentication flow for a security key e.g. a Yubikey. After adding these options:

     authenticatorSelection: {
        residentKey: "required",
        userVerification: "preferred",
      }

Any devices that were registered with a Yubikey stopped working. I then removed the Yubikey device, and registered it again and noticed I was prompted to use a pin (this didn't used to happen).

I was wondering if there is a way to make these older Yubikey devices still work? Or is the only solution to force users to register them again with a pin.

Thanks.

[MasterKale]

Ah, to clarify, are you asking about the fact that your Android experience went from this...

...to this?

If so, then the reason is that residentKey: 'required' opts you into Android's new passkey user experience. As far as I can tell it's not possible to use security keys in this state, even if you set authenticatorAttachment: 'cross-platform'.

I think Google is planning to make it possible to use security keys here, eventually, but I'm not privy to any deadlines. This would be a good thing to post to the fido-dev mailing list and see if anyone from Google responds (they definitely read the mailing list.)

[MasterKale]

(Forgive the inconsistency in the screenshots, those were the ones I had on hand 😂)

[hwhmeikle]

Thanks for the speedy reply!

Not confused as to why the Android UX changed (that's what we were hoping to accomplish with these changes.). Just wanting to seek clarity on why the UX has changed for security keys as a result.

Before making this change I could add a security key and was not required to provide a pin, but now I am. This would be fine except for the fact that any security key that was registered before these changes no longer works (unless removed and registered again with a pin).

I suspect it's either residentKey: 'required' or userVerification: "preferred" that has introduced the need to provide a pin. To your knowledge would there be anyway to authenticate a security key that was registered before these options were introduced (and therefore has no pin associated with it)?

Cheers!