- From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Sep 2019 21:42:43 +0000
- To: public-webauthn@w3.org
While this is a nice idea, had we started afresh, this brings more confusion and incompatibilities to existing otptions. Also, it is restricting the usage over time which can change over time for the RP. For example, if RP which chooses residentKey=preferred, UserVerification=preferred. And for now it uses these resident credentials it as second factor as its customers are hybrid. Some have older U2F keys and some have newer FIDO2 keys. It gives RP an option to migrate over time from second factor to sole first factor over time when all of it's users have such type of credential. Point is we support these kind of transitions now and consolidating it to only one type of use case has a counter affect. I am actually confused with definition of "alternate-first-factor" vs "sole-first-factor discussoin here and why does the difference is between residentKeys options above. UserVerification controls whether RP wants 2FA/first factor/alternate-first-factor. Resident keys reflect whether RP is going for usernameless/typing-free experience. residentKeys=required, userverification=required -> mainlyl usernameless passwordless flows. Or sole-first-factor definition here. However, it can be used in second factor initially if RP wants to transition smoothly for its mixed variety of users. residentKeys=preferred, userverification=required -> I am confused with this choice. Either you put residentkeys=discouraged/userverification=required if you don't want usernameless flows or RP puts above residentKeys=required, userverification=required for usernameless flows. I would love to understand more about this choice. Now the other point that @agl mentioned was around what happens when there is a mismatch between options passed explicitly between this option and all other options. Which one takes precedence and why. And how to tell the RP that browser interpreted the mismatch it this way. I am worried about these options are only narrowly defining some use cases are and not as flexible as specifying individual options as available and deployed by many parties. I would put these clarifications and use cases to options mapping for an RP to understand. As it is attempted in #1300. -- GitHub Notification of comment by akshayku Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1292#issuecomment-532878677 using your GitHub account
Received on Wednesday, 18 September 2019 21:42:45 UTC