webauthn - API need to know the registration status of an platform authenticator

[mkkhedawat]

Facts

• Multiple devices require multiple registrations
• Workaround ways to know if a user is registered for RP on the current device
  • Persistent cookie
  • User Agent manipulation
• When you call a support center, the first solution anybody provides is clear cookies 🥇
• UX via User-Agent is strongly discouraged
• Resident credentials have a lot of zombies

Problems

• Clearing cookies is common enough, results in frequent registrations
• If one uses User-Agent
  - ends up limiting one type of device per user, Two windows devices will fail.

Will it make sense if we had an API that doesn't require user intervention and can tell us if credential X is available to provide assertion on current(or given) RP?

That way we can prompt for assertion only if credentials available on the server are accepted on the current device otherwise follow the registration process.

[agl]

We would not add an API that silently reports whether a credential is present on the current machine because that would create an inappropriate tracking vector.

There is a problem that creating a credential can overwrite an existing credential. There is a proposal to adopt Window's current behaviour to avoid that.

(You say above that “Resident credentials have a lot of zombies”. That suggests that the user handle isn't being set correctly: there should only be a single discoverable credential per (RP, user handle) on a given authenticator.)

In terms of knowing whether a credential exists for signing in, there is also a proposal to integrate with autocomplete for that.

[mkkhedawat]

Thank you, This helps.

Agree on the tracking aspect. While credentialID itself is not guessable but if RP identifies the user via other means, This API can be misused for device verification. I take back the silent report. Maybe we add a consent like "Website X is trying to check if you are registered ..., Allow, Deny" to counter that.

Let me add more context to my problem (check out the video)
https://user-images.githubusercontent.com/5137374/124510194-e80d3000-ddf0-11eb-9e36-6dc09a37f9cb.mp4

When we prompt for assertion with an allow list and if credentials are not there, Browsers fall back to the default screen with the security key option. If user cancels the screen, as an app owner I won't know for sure if it was a sensor issue, it was canceled intentionally or credentials were not there as in all cases the error is generic. Same privacy concern. Unless I am sure, prompting for registration hinders the user experience especially in enterprises where registration requires two-factor authentication. Showing broken assertion on a new device is also not a good experience. Then there comes the use case where keychain is wiped, webauthn gets broken on Mac but the persistent cookie is still there.

While the combination of persistent cookies and canceled assertions works as a workaround in most cases, I am wondering if we could get first-class support for such use cases. If not a status API, what are our options?

[mkkhedawat]

In terms of knowing whether a credential exists for signing in, there is also a proposal to integrate with autocomplete for that.

Will autocomplete throw a different error if I provide a user whose credentials don't exist on the device.

In my case I know who the user is, I even have some possible credentials. I just want to be sure that credential exists before/during assertion.

[agl]

When we prompt for assertion with an allow list and if credentials are not there, Browsers fall back to the default screen with the security key option.

You can set the transports member of the credentials to “internal” to tell the browser that the credentials cannot come from an external security key. It'll still show a dialog and wait for the user to close, but it shouldn't offer a external option that'll never work.

While the combination of persistent cookies and canceled assertions works as a workaround in most cases, I am wondering if we could get first-class support for such use cases. If not a status API, what are our options?

The autofill integration is the current proposal for this.

In my case I know who the user is, I even have some possible credentials. I just want to be sure that credential exists before/during assertion.

If you know who the user is, then you have state (e.g. cookies). If you have such state then you can record whether the user signed in with WebAuthn initially. If so, then you should request an assertion and pass all the credential IDs for that user. It's possible that they deleted the applicable credential since signing in, but that seems like a very narrow case.

If you're doing a sign-in from fresh state then the autocomplete proposal says that you'll be able to mark a text field as suitable for WebAuthn autocomplete and the assertion request will request a promise that will only be resolved if the user selects a WebAuthn credential to use.

[mkkhedawat]

Awesome. Looks like autocomplete will sort things out.

If you know who the user is, then you have state (e.g. cookies). If you have such state then you can record whether the user signed in with WebAuthn initially. If so, then you should request an assertion and pass all the credential IDs for that user. It's possible that they deleted the applicable credential since signing in, but that seems like a very narrow case.

On a general day, Yes a narrow case. But during the OS upgrade season, it is not. In our recent Big Sur migration, we saw many examples where the platform authenticator broke but cookies were intact. I hope that also gets stable over time.

[agl]

In our recent Big Sur migration, we saw many examples where the platform authenticator broke but cookies were intact.

There have been other reports of such issues when updating to Big Sur. Do the cases that you have observed have Crowdstrike installed? There is an unconfirmed suggestion that there's a bad interaction.

[mkkhedawat]

Yes, We do have crowd strike. Saw a similar thread on the Chromium issue pages as well.

[equalsJeffH]

from #1639 (comment) above:

Awesome. Looks like autocomplete will sort things out.

https://www.w3.org/2021/07/14-webauthn-minutes.html says:

… lets wait for comments then we can resolve.

There's been no further comments, shall we close this issue?

[equalsJeffH]

closing....