We observed a behaviour which may be technically correct, but confusing to RPs.
Because of how CredProtect-3 is used in chromium, it will make passkeys seem to not exist.
I believe the behaviour and problem is related to this change/thread: https://lists.w3.org/Archives/Public/public-webauthn-adoption/2023Mar/0000.html
Scenario:
A Passkey gets created with the following properties on a USB security key:
discoverable: required
uv: preferred
During authentication, the passkey will suprisingly work/not work depending on the options set:
If UV is discouraged during assertion
... and allowCredentials is empty - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.
... and allowCredentials contains the credId of said passkey - Chromiums "use security key"-dialog will return "You're using a security key that's not registered with this website" - FAILING to authenticate
if UV is preferred
... and allowCredentials is empty - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.
... and allowCredentials contains the credId of said passkey - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.
I'm surprised how the use of allowCredentials causes the Security Key to be unusable, instead of simply requiring UV to enumerate. Either, this could be considered a bug in chromiums implementation OR we should provide documentation on this behaviour for RP's OR that allowCredentials should never be used with discoverable passkeys(?)
Summary
We observed a behaviour which may be technically correct, but confusing to RPs. Because of how CredProtect-3 is used in chromium, it will make passkeys seem to not exist. I believe the behaviour and problem is related to this change/thread: https://lists.w3.org/Archives/Public/public-webauthn-adoption/2023Mar/0000.html
Scenario:
During authentication, the passkey will suprisingly work/not work depending on the options set:
If UV is discouraged during assertion
allowCredentialsis empty - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.allowCredentialscontains thecredIdof said passkey - Chromiums "use security key"-dialog will return "You're using a security key that's not registered with this website" - FAILING to authenticateif UV is preferred
allowCredentialsis empty - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.allowCredentialscontains thecredIdof said passkey - Chromiums "use security key"-dialog will allow it to be touched, require UV and then used SUCCESSFULLY.I'm surprised how the use of
allowCredentialscauses the Security Key to be unusable, instead of simply requiring UV to enumerate. Either, this could be considered a bug in chromiums implementation OR we should provide documentation on this behaviour for RP's OR that allowCredentials should never be used with discoverable passkeys(?)Video replicating the problem: https://share.cleanshot.com/DXKJGG9f
Proposed Content Type
Protocol Deep Dive, Other / Unknown