Matthew Miller

> I updated my comment. We talked about adding something equivalent to `cross-device` to cover both hybrid and security-keys and any other future non-local option. Hmm, what's the current gap...

> @MasterKale, order matters with hints; so to be clear, you were intentional in placing `"security-key"` before `"hybrid"`, right? No, I was not intentionally ordering the hints in that comment....

> This means that the countably infinite `[PublicKeyCredentialHints]?` is partitioned into five equivalence classes, correct: > > 1. `[]` > 2. `["security-key"]` > 3. `["client-device"]` > 4. `["security-key", "hybrid"]` >...

> Is this true? The spec says "if two hints are contradictory, the first one controls" which seems to imply that something like `["security-key", "client-device"]` is equivalent to `["security-device"]` due...

**From WAWG meeting @ 5/1:** there's potential value in keeping `authenticatorAttachment` around while making `hints` into a further refinement of existing client behavior for a given attachment. This would mean...

> Please keep in mind the concern that WebAuthn should not leak information about whther or not the user has credentials to the RP without user consent. Good call out...

@sbweeden please take a look at my comment immediately above from a month ago, I'd definitely value your input here too.

@nsatragno helped me understand last week that, unfortunately, `NoCredentialsError` needs to be removed from consideration. If malicious code executed `.get()` on a site on which the user has no credentials,...

I'm closing out this issue for a new one, #2096, to consolidate the discussion around the five new errors I want to try and add to WebAuthn.

> Is this a counter-proposal to the #2021 PR? If so, I prefer the semantics of #2021 which allows the RP to specify in extension input a preferred max time...