- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jan 2021 05:02:04 +0000
- To: public-webauthn@w3.org
Agree with @nadalin - the adoption community is the right place for this discussion. I do have a POV on the scenario: I would not try and implement such a scenario with a single WebAuthn call - it seems awfully prone to end user confusion. w.r.t. the Yubikey part of the scenario, I don't know precisely what was meant by "a password to be *issued* after" - but assume it is meant to say that the user should also *supply* a password after. If I were to *attempt* such a scenario I would set userVerification=discouraged in the WebAuthn call, supply an empty allowCredentials list (because the user has not yet been authenticated then none can be used), and on receiving an assertion response I would check the uv bit in the supplied authenticatorData to then make a determination as to whether to additionally require a password or not. When using TouchID, the authenticator should set uv in the authenticatorData if it verified the data, *even if* the RP set discouraged for userVerification when offering it's parameters to the client. -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1510#issuecomment-764328768 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 January 2021 05:02:10 UTC