search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.19k stars 172 forks source link

The authenticator may hide the credential even if the RP signals unknown credentials #2192

Open Kieun opened 3 weeks ago

Kieun commented 3 weeks ago

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.

WebAuthn Relying Parties may use these signal methods to inform authenticators of the state of public key credentials, so that incorrect or revoked credentials may be updated, removed, or hidden.

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).

timcappalli commented 3 weeks ago

@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.

Kieun commented 3 weeks ago

Yes, it seems better not to provide such hidden feature for signal APIs.

timcappalli commented 3 weeks ago

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.

Kieun commented 3 weeks ago

There are some procedures regarding the way of handling such signals for authenticators in the spec. It also contains description that the credential would be hidden or removed. So, I think the current spec defines the conformant authenticator behavior and it allows hidden policy for the credential.

timcappalli commented 3 weeks ago

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.

Kieun commented 3 weeks ago

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 When the user deletes a certain passkey on the passkey setting menu on the RP website, It might be recommended to change such credential state to hidden (instead of deleting it from the database) so if the passkey is restored on the passkey provider, it would still works. But, this would break some RP's implementation to handle this situation.

nsatragno commented 1 week ago

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 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.

Kieun commented 1 week ago

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.

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. What do you think so?

We could add some notes around how authenticator may communicate with users when restoring the credential.