-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The authenticator may hide the credential even if the RP signals unknown credentials #2192
Comments
@Kieun what is the specific change you're recommending? I think you're suggesting that "hidden" should be removed? There was loose consensus inside FIDO that some authenticators may wish to "move a passkey to the trash", which would effectively hide it from a WebAuthn ceremony, and then permanently delete it at a later date. The actual lifecycle would be authenticator-specific. |
Yes, it seems better not to provide such hidden feature for signal APIs. |
It is not a "feature" per se. Authenticator lifecycle is authenticator-specific and the RP Signals feature is opportunistic and does not dictate authenticator behavior. |
There are some procedures regarding the way of handling such signals for authenticators in the spec. |
Yeah, that's fair. I still think we should keep it as there are authenticators who have expressed interest in offering this capability. |
What is the rationale? RP might accidentally call the signal APIs due to bug? If there is credential hidden policy for this signal APIs, RP might need similar policy on their backend side |
Yes.
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 is doing hard deletion right now as we hone the implementation, but we have plans to switch to hiding / restoring next year.)
We do not specify what authenticator dedicated UI does, and reporting from the authenticator to the site is out of scope of this feature. |
Understood. If it is the case, I recommend that the authenticator would notify the user that the recovered credential may not work when the user tries to restore the hidden credentials from the authenticator. We could add some notes around how authenticator may communicate with users when restoring the credential. |
Proposed Change
In the spec, there are some description and recommendation how the authenticator handles signal APIs.
Currently, in many parts, there are description like this.
The authenticator may decide not to remove the credential at the time of receiving the signal and it may remove it after certain amount of time passes. It implies that the credential would not delete the credential and for some reasons the hidden credential would be changed to active credential.
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. So, for this case, the authenticator would hide the credential if the user deletes the credential through menu and it would be restored depending on some cases, and it would still work without any issue.
For this scenario, the hidden feature might be a good choice as an authenticator to prevent the credential is accidentally removed so that the user avoid user lock out case.
However, for the signal APIs, RP indicates that the acceptable credentials with an intention, so It would be better for authenticators to delete or update credentials if it is required to meet the original requirement (synchronization between authenticators and RP).
The text was updated successfully, but these errors were encountered: