Hi everyone, Many thanks for your answers so far, Indeed, setting explicitly the credProtect value seems to be the answer. But I think part of the discussion missed one point: credProtect is supported for both server-side and client-side credentials – and (to my knowledge) several implementer have backward compatibility between CTAP2 server-side credentials and CTAP1*. So the default behavior of Chrome when registering a new credential on a CTAP2.0+/2.1 security key will be to create a server-side credential with credProtect 3 – and this credential is expected not to work on Android. Best regards, * I wouldn’t say this is backward compatibility, I’ve always considered this as just a change in the application layer protocol, so U2F key handles and CTAP2 server-side credentials are the same thing; which is also why alwaysUv and credProtect have interactions with U2F. This was, and is still, important in the transition between U2F and FIDO2 while many devices don’t support CTAP2 yet, but many already “dropped” U2F for security keys that supports CTAP2.0 and higher. -- Thomas Duboucher From: Adam Langley <agl@google.com> Sent: vendredi 10 mars 2023 20:42 To: John Bradley <jbradley@yubico.com> Cc: DUBOUCHER Thomas <thomas.duboucher@thalesgroup.com>; Martin Kreichgauer <martinkr@google.com>; W3C Web Authn WG <public-webauthn@w3.org>; public-webauthn-adoption@w3.org Subject: Re: Upcoming changes to Chrome’s WebAuthn implementation (Chrome 112 / 113) On Fri, Mar 10, 2023 at 7:02 AM John Bradley <jbradley@yubico.com<mailto:jbradley@yubico.com>> wrote: I don’t think this really breaks anything in practice. RP can however will need to set uv discouraged on make if they set it on get. I just want to highlight something from the linked documentation: if the RP sets an explicit credProtect level in the WebAuthn request, that overrides any of these defaults. The defaults are intended to prevent unpleasant surprises, but RPs don't have to accept them. Cheers AGL
Received on Wednesday, 15 March 2023 10:09:46 UTC