- From: Manish Khedawat via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jul 2021 20:00:20 +0000
- To: public-webauthn@w3.org
Thank you, This helps. Agree on the tracking aspect. While credentialID itself is not guessable but if RP identifies the user via other means, This API can be misused for device verification. I take back the `silent` report. Maybe we add a consent like "Website X is trying to check if you are registered ..., Allow, Deny" to counter that. Let me add more context to my problem (check out the video) https://user-images.githubusercontent.com/5137374/124510194-e80d3000-ddf0-11eb-9e36-6dc09a37f9cb.mp4 When we prompt for assertion with an allow list and if credentials are not there, Browsers fall back to the default screen with the security key option. If user cancels the screen, as an app owner I won't know for sure if it was a sensor issue, it was canceled intentionally or credentials were not there as in all cases the error is generic. Same privacy concern. Unless I am sure, prompting for registration hinders the user experience especially in enterprises where registration requires two-factor authentication. Showing broken assertion on a new device is also not a good experience. Then there comes the use case where keychain is wiped, webauthn gets broken on Mac but the persistent cookie is still there. While the combination of persistent cookies and canceled assertions works as a workaround in most cases, I am wondering if we could get first-class support for such use cases. If not a status API, what are our options? -- GitHub Notification of comment by mkkhedawat Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1639#issuecomment-874304845 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 July 2021 20:00:22 UTC