Closed reavowed closed 1 year ago
Thanks for the report! Sorry, this is a very much unintended regression in versions 2.0.0
to 2.4.0-RC1
, inclusive. It should be fixed in commit 1dcf4307de94fb847a1fe29822744555815d42b4 which is released as pre-release 2.4.0-RC2
, available on Maven Central now. (There's a delay before it shows up in the web search UI, but it is already available for build tools to download.) A note about this has been added to the migration guide too.
The fix has been out for a while now, so I'll close this. Please let us know if you're still having issues with this.
I'm using this library in a webserver using discoverable credentials for user login. I recently updated to v2.3.0, and discovered that my registration journey was broken - when I registered, my authenticator was creating a non-discoverable credential, and I was subsequently unable to log in.
It looks like the authenticator I'm using to register doesn't support the new
residentKey
property in Webauthn level 2 (which I have set torequired
). The Webauthn spec says of the previously-usedrequireResidentKey
property that it is "retained for backwards compatibility with WebAuthn Level 1" and "Relying Parties SHOULD set it to true if, and only if,residentKey
is set torequired
". However,AuthenticatorSelectionCriteria
has no support for outputting this property, so to keep discoverable credentials working on the devices we have, I have to manually set the oldrequireResidentKey
property totrue
in the client-side javascript.It would be nice if this library just set the old
requireResidentKey
property automatically ifresidentKey
has the appropriate value. Alternatively, the migration guide should probably mention that backward-compatibility might be broken!