makeCredential should be more precise than NotAllowedError in its last step

[jyasskin]

https://w3c.github.io/webauthn/#makeCredential ends with

Reject promise with a DOMException whose name is "NotAllowedError".

However, it can get to this step for a couple reasons besides the user disallowing the operation.

• "If the adjustedTimeout timer expires," it should return a https://heycam.github.io/webidl/#timeouterror
• "If any authenticator returns a status indicating that the user cancelled the operation," NotAllowedError might make sense, but https://heycam.github.io/webidl/#aborterror might make more sense for the user cancelling.
• "If any authenticator returns an error status," should we propagate that error? I see UnknownError, NotSupportedError, and NotAllowedError in https://w3c.github.io/webauthn/#op-make-cred. The UnknownError there also looks suspicious to me. That could be a TypeError.

[vijaybh]

Just to add a bit of historical context, the current behavior is an attempt to balance providing feedback to the RP with maintaining privacy for the user. Might be a useful exercise to think through what's the most an RP can infer from the differences between these errors.

[jyasskin]

It'd be good to extend the Privacy Considerations section to list the attacks we want to prevent. Without that, we aren't going to be rigorous about it.

[jyasskin]

I've filed #382 to track the privacy considerations extension.

[selfissued]

It seems to me like there's probably consensus to maintain the current behavior, for privacy reasons. If so, we should decide that and close this issue. Whereas, if we're going to make a change, we should do so before the Implementer's Draft, since it would affect interop.

[nadalin]

@selfissued Can you please close per your last comment on privacy

[selfissued]

Closing with no action per the privacy comment above.