- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Jun 2022 22:56:45 +0000
- To: public-webauthn@w3.org
> Wouldn't DPK support (PR#1663) be sufficient? Essentially not preventing the multi-device key, but ensuring an additional single-device key being established _per device_. DPK is only known *after* the authentication and would be rejected by the RP during that process. And it relies on the authenticator providing DPK. Imagine the workflow here as: * RP sends challenge * Client browser presents a UI for what authenticators are viable * Authenticator is chosen and interacted with * Browser sends response to RP * RP either accepts or rejects the registration * Client browser renders success or error. Right now, we have to do this *full* process, and then render and error at the end. That then means the error has the burden to communicate to the user *why* their authenticator was not allowed to be used in this context. But this isn't nice for the user. We have a step here near the start - the browser presents a UI for what authenticators are viable. If at that point we imposed a constraint, then we never need to error and communicate that to the user. They have a subset of their authenticators that are "more likely" to succeed in the ceremony. This is a better user experience, it's a lot easier to communicate to users, and RP's can produce a better workflow. DPK would again, be sending is back to that full-error process, the same as "check the backup bits". What is being asked for here is the ability to guide that UX in a way that we have constraints available. For more of a summary about this https://www.sachinrekhi.com/don-norman-principles-of-interaction-design -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1739#issuecomment-1155787051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 June 2022 22:56:47 UTC