- From: Nina Satragno via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Nov 2024 20:58:43 +0000
- To: public-webauthn@w3.org
> What is the rationale? RP might accidentally call the signal APIs due to bug? Yes. > However, for the signal APIs, RP indicates that the acceptable credentials with an intention, Experience with HSTS preloading indicates that given the scale of the web, sharp APIs must have some way to undo damage from improper use. Many tears have been shed for a misplaced API call. Someone (probably, lots of people) may hold the API wrong and clear user passkeys. However, it's not going to be possible to implement hiding and restoring for every authenticator, e.g. Windows Hello and security keys don't have a "hide" functionality. Thus, the language we chose to standardize. (as an aside, [Google Password Manager](https://developer.chrome.com/blog/passkeys-signal-api?hl=en) is doing hard deletion right now as we hone the implementation, but we have plans to switch to hiding / restoring next year.) > In the case of the user directly goes through the authenticator dedicated UI and then delete the credential, it would not be reported to the RP and which causes credential mismatch. We do not specify what authenticator dedicated UI does, and reporting from the authenticator to the site is out of scope of this feature. -- GitHub Notification of comment by nsatragno Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2192#issuecomment-2474770293 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 November 2024 20:58:44 UTC