- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Mar 2019 16:55:16 +0000
- To: public-webauthn@w3.org
Cristian I see your argument for disallowed if CTAP changes the pin rules for creating non resident and keeps the pin as a requirement for resident. I think we still have a problem if in your tri state allowed is interprited as the platform making it resident if it can. I suspect that we really have 4 states. Reqired - Must be resident or error (Same as current true) Preferred - Create a resident credential if possible, but can return non resident if that is the only option Allowed - Create a non resident credential, but for authenticators that only support resident allow those to be created. (Same as the current false) note Windows and potentialy Android platform authenticators currently allways make resident credentials Forbidden - make a credential that requires an allow list and won't require a device pin or UV (platform authenticators can flag credentials to require the allow list to avoid returning an error. We don't really want authenticators returning errors for Forbidden. That would cause RP to avoid using it. I take it that what you want with forbidden is really just that the user is not prompted for PIN or UV just UP top make a credential. The allow list requirement is really just a way to get that based on the proposed CTAP changes. If CTAP didn't require a PIN/UV for make credential if UV is not required in the request then you might not need forbidden? Just trying to inderstand the interaction between this and the proposed CTAP changes. Not all authenticators have infinate space for resident credentials. Our current options of resident required and -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/991#issuecomment-472961535 using your GitHub account
Received on Thursday, 14 March 2019 16:55:19 UTC