- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jan 2021 23:37:29 +0000
- To: public-webauthn@w3.org
> I'm a bit confused though as to why credentials themselves should dictate their use, since the RP can decide to approve or deny the credentials as it sees fit. We shouldn't put further onus on the authenticator (or credential itself) to provide an enforcement I think the core of this discussion that perhaps is being overlooked is the framing. With regard to the webauthn specification, with a single authenticator attached to the browser, and the account having multiple identical authenticators associated there is no problem. When you include the more complex scenarioes - accounts with touchid (verified MFA authenticator) as well as a yubikey + password (multiple single factors), then these can't be expressed in the workflow. Webauthn today expresses a single userVerification policy for the entire set of *all* possible authenticators associated to the account. This is incompatible with advances to more rich and dynamic mixed credential policies. The browser is fundamentally involved in this process as it describes to the authenticator *if* it requires verification or not. So while the RP can accept/deny based on internal knowledege, that is not reflected in the webauthn specification that the browser should be able to set per-authenticator verification requirements that *match* what the RP expects. This leads to surprising and inconsistent behaviour that may confuse users or lower trust in the system. In some cases depending on the RP implementation and assumptions, it may lead to verification bypass reducing MFA authenticators to single factor. I believe that my PR #1547 may help further to express how a per-authenticator verification policy could be expressed in the webauthn standard to resolve this. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1510#issuecomment-764028940 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 January 2021 23:37:31 UTC