Re: [webauthn] Add two abort paths for getting an assertion

> Can't this be covered by the existing AbortError path?

Do you mean that it could be merged with the subsequent case because the actions are almost identical? I agree and the only reason that I included a separate (and very similar) case was because the disjunction of the two conditions seemed excessively complex when written. Totally don't care about which way to structure this, however.

(Although I do thing there is value in returning a `NotAllowedError` in this case, see below:)

> I think it must be made much clearer that this requires active and informed consent to reveal credential existence to the RP.

Why does this disclose credential existence? I think all the following situations should look the same to the RP:
1. The user activates some UI to abort the operation. (For example, Firefox currently has a “Cancel” button in a bubble that does this.)
1. The user presses the wrong authenticator. (The spec doesn't allow this, but both Chrome and Firefox flash all authenticators and abort the operation if the wrong one is pressed.)
1. An internal authenticator matches, but the user activates some system UI to abort using it. (For example, triggering Touch ID on iOS shows _system_ UI that allows the operation to be canceled.)
1. (_This case_) The client concludes that the operation is doomed and lets the user press the same sort of cancel button as in case one.

Now, in practice Firefox and Chrome are returning different errors for many of these cases and I think that should probably be fixed. But, assuming that we manage that, I don't see that we're leaking information about the presence of the credential here.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/906#issuecomment-390305235 using your GitHub account

Received on Friday, 18 May 2018 19:13:06 UTC