- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Nov 2022 21:36:49 +0000
- To: public-webauthn@w3.org
@emlun I think this is a good and timely point, and has also been raised as feedback on the passkeys dev site ( https://github.com/passkeydeveloper/passkeys.dev/issues/63 ) by myself. I think that the preferred-if-unlimited is a good naming, alternately preferred-if-unbounded also works. I think that indifferent/any don't really communicate the intent. weakly-preferred also doesn't really convey this. Weakly-discouraged kind of conveys "always try to make this" and again doesn't really work here. Saying this, how is this setting any different today to "discouraged"? """ This value indicates the [Relying Party](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#relying-party) prefers creating a [server-side credential](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#server-side-credential), but will accept a [client-side discoverable credential](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#client-side-discoverable-credential). """ We already have authenticators that will always create an RK under discouraged, so I think we would need to also discuss how this is different from the perspective of a browser/user-agent and how they interact with authenticators. Their interactions need to be deterministic over ecosystems too. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1309406548 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 November 2022 21:36:51 UTC