### 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:** * 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(?) Video replicating the problem: https://share.cleanshot.com/DXKJGG9f ### Proposed Content Type Protocol Deep Dive, Other / Unknown