Use of exclude list while bootstraping.

[akshayku]

This document have empty excludelist while bootstraping the platform authenticator. With user experience same as with or without exclude list, I think it's better that we include excludelist so that existing credentials don't get overwritten as it is happening now.

This came as part of PR #28 discussion where we are asserting that storing credentialID on the client is not required if we already have indication that local FIDO credentials exist.

@ve7jtb :

I suspect the real solution is resolving problems with exclude lists.
Perhaps at the WebAuthn level we need a single command that is:
1 If no credentialID is found in the exclude list then make credential and return
2 do getAssertion with exclude list as allow list.

Windows when finds that existing credential exists in the allowlist, creates a dummy credential (different dummy RP) and goes through the motion of authenticating the user. API returns an error and RP gets InvalidStateError. But from the user's perspective, they have authenticated. And they don't have to cancel the operation.

When InvalidStateError happens, RP can choose to store local variable which says that FIDO credentials exists on the platform. So having an exclude list during bootstraping should not be an issue on Windows as user experience is good. Just tested on Android and there also user authenticates and specific InvalidStateError happens. Not sure about iOS experience.

So I don't see why we cannot include "excludelist" into this document as a recommendation so that we don't end up in overwrite situation in the first place.

[sbweeden]

I would find it difficult to support this idea based on the current Apple experience.

If I already have a registered platform credential and call create with authenticatorAttachment set to platform and include the existing credential in the excludeCredentials list, I get a UX dialog box error saying the credential is already registered:

Then after dismissing that dialog the API receives: NotAllowedError: This request has been cancelled by the user.

Consistency and a smooth user experience is what this document is all about. If we can't put consistency into the specifications themselves for platform authenticators, and the browser vendors continue to have different POV's on what UX they want to offer (i.e. there is no uniformity in the experience), then we have to settle for the either branching on functionality based on browser detection in client-side Javascript (awful), or adopting a pattern that provides the least-bad experience across all the platforms.

Best I can tell today that requires an empty excludeCredentials list for the UVPA adoption pattern.

[akshayku]

Got it. Thanks for the update.

[eldanb]

@akshayku @sbweeden given the discussion above, and specifically the fact that some browsers (e.g Apple) render the excludeCredentials list unsuitable for a uniform UX, can we close this issue?

[sbweeden]

I am ok with that - @akshayku can re-open if there's still more to discuss.

[akshayku]

I am reopening it. This issue still persists and see the latest discussion around it at w3c/webauthn#1637 where we are trying to do a consensus around it.

[akshayku]

In w3c/webauthn#1637, we are proposing that RP always include all the credentials known to it for a user in both MakeCredential and GetAssertion