- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Nov 2022 12:43:26 +0000
- To: public-webauthn@w3.org
Looking at L2 we don't need a spec change. preferred This value indicates the [Relying Party](https://www.w3.org/TR/webauthn-2/#relying-party) strongly prefers creating a [client-side discoverable credential](https://www.w3.org/TR/webauthn-2/#client-side-discoverable-credential), but will accept a [server-side credential](https://www.w3.org/TR/webauthn-2/#server-side-credential). For example, user agents SHOULD guide the user through setting up [user verification](https://www.w3.org/TR/webauthn-2/#user-verification) if needed to create a [client-side discoverable credential](https://www.w3.org/TR/webauthn-2/#client-side-discoverable-credential) in this case. This takes precedence over the setting of [userVerification](https://www.w3.org/TR/webauthn-2/#dom-authenticatorselectioncriteria-userverification). The platform can already use its judgement on how to treat a strong RP preference. Before CTAP2.1 the platform did not know how many resident slots remained. Perhaps this would be more appropriate for the CTAP2.2 platform guidance to have a non normative note in making the credential that if webauthn is set to preferred then rk=true should only be sent if remainingDiscoverableCredentials has a value of 25 or greater. I don't think we need a change in WebAuthn. -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1310226160 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 November 2022 12:43:27 UTC