- From: Max Hata via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Sep 2020 04:58:06 +0000
- To: public-webauthn@w3.org
> I don't agree that this also applies to the discoverable keys (username-less) use case, as the server then returns only a challenge to initiate the ceremony. If the server only supports username-less authentication, I don't see how this issue can occur. It remains if the server supports both discoverable and non-discoverable keys, though. For discoverable keys, there are two deployment scenarios: Case A: allowCredentials=empty Case B: allowCredentials=credentialIds I agree, there is no credentialId exposure issue with Case A. But there is credentialId exposure issue with Case B. So why RPs deploy Case B? When you are deploying on multiple platforms, certain platforms do not support discoverable keys and others do. If RPs use common denominator approach (same flow and same UX for their consumers), they tend to use allowCredentials=credentialIds for all platforms, and this choice brings about the credentialId exposure issue even for platforms that do support discoverable keys. So the spec should remind RPs about this risk if they use common denominator approach. -- GitHub Notification of comment by maxhata Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1475#issuecomment-685296465 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 September 2020 04:58:08 UTC