Re: [webauthn] keyType: "public-key" is superfluous

re/ adding UAF-style assertions to webauthn because we might want to re-use existing UAF keys over CTAP - what would the user experience be for this? Am I imagining this right:

1. User launches PayPal app on phone, which is UAF capable, but before the CTAP update.
2. PayPal app says "hey, let's use fingerprints instead of passwords next time", and uses UAF to accomplish this. Note that the user is still a password user for PayPal, and would use a password to log into PayPal from any other device.
3. Some time later, user launches PayPal app on this phone, does fingerprint, logs in using UAF. Yay! But note that the user is still a password user for PayPal, and would use a password to log into PayPal from any other device.
4. The CTAP update happens for the phone.
5. User goes to paypal.com on their laptop, and types their username ... and their password? (Isn't that what would happen? Why would the user go through the trouble of getting their phone, pairing it with the laptop, waiting for a prompt on the phone, and then use their fingerprint, if they can just log in with their password?)
6. On the laptop, paypal.com says "hey, let's use Windows Hello instead of passwords next time", and uses webauthn (locally on the laptop) to accomplish this.

In other words, I'm not sure why re-using existing UAF keys over CTAP is an important use case. CTAP is for external authenticators, which are used in situations where the user _doesn't_ have a password (or must use the authenticator in addition to the password), which is not what UAF is used for on the millions already-deployed phones.

If, in the future, some of the millions already-deployed phones will be used in a context where they _are_ an external authenticator (e.g., when the user signs up for 2-factor authentication for a service), they can simply create a new webauthn-compatible key pair.

-- 
GitHub Notification of comment by balfanz
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/554#issuecomment-329649376 using your GitHub account

Received on Friday, 15 September 2017 01:10:25 UTC