From d0dc7dce73f33b0637bdac125bfa6abbd02b1de0 Mon Sep 17 00:00:00 2001 From: Chris Mills Date: Fri, 17 Jan 2025 12:41:49 +0000 Subject: [PATCH] Fix for agektmr review comment --- .../publickeycredential/signalunknowncredential_static/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/files/en-us/web/api/publickeycredential/signalunknowncredential_static/index.md b/files/en-us/web/api/publickeycredential/signalunknowncredential_static/index.md index 0f13e61660b9e04..824f469c8d296e6 100644 --- a/files/en-us/web/api/publickeycredential/signalunknowncredential_static/index.md +++ b/files/en-us/web/api/publickeycredential/signalunknowncredential_static/index.md @@ -16,7 +16,7 @@ It is possible for the information stored in a user's authenticator about a [dis The next time they try to sign in with a discoverable credential, the deleted credential will still be presented in the relevant UI, but the attempt to sign in will fail because the server won't recognize it. This results in a confusing user experience. -After this happens, `signalUnknownCredential()` can be called on the relying party site to tell the authenticator that the credential ID was not recognized. It is up to the authenticator how to handle this information, but the expectation is that it will delete the relevant credential so that the same confusion does not occur again. +To avoid this issue, `signalUnknownCredential()` should be called on the relying party site each time a discoverable credential-based sign-in fails, or when a discoverable credential is created but fails to be stored on the server for some reason. This tells the authenticator that the credential ID was not recognized. It is up to the authenticator how to handle this information, but the expectation is that it will delete the relevant credential so that the same confusion does not occur again. ### `signalUnknownCredential()` versus `signalAllAcceptedCredentials()`