The deregister web service is used to delete a registered FIDO key either by an authenticated user who owns the credential or a FIDO administrator/security officer at an RP site.

NOTE: Once a credential is deleted, the credential may never be used again on the RP site. However, it is possible for the user to register the same Security Key or platform device (mobile, laptop, or desktop) to the same RP site, and each of these devices will generate a completely new credential on that site.

Warning: If there is only one Credential left for a particular user and the Delete web service is called with the correct credential. SKFS will complete the delete operation and users might lock themselves out. It is the Web Developer's responsibility based on the Applications policy to deal with this scenario.

It is important to understand, that in the SKFS default security settings, it is NOT possible to restore a deleted FIDO credential from a backup of the database. To preserve the integrity of the credentials—there is a known vulnerability in the FIDO protocols where an attacker who has previously (and legitimately) registered a FIDO credential at that site may be able to add their credential to another user’s account if they were to compromise the RP site database or if the application was susceptible to a SQL injection attack.

In such a situation, the a FIDO server would be unable to tell that the attacker’s credential was spurious and does not belong to the legitimate user of the account. Consequently, it would allow the attacker to authenticate as the legitimate user at that site with the attacker’s credential.

This attack works, because unlike X.509 digital certificates, which bind a user’s distinguished name (DN) with their public key, the FIDO protocol does not create a binding between the username and their public key. As a consequence, a FIDO server that was unaware of the potential of this attack would be unable to tell that, from among a set of registered credentials for a user, which of those credentials are legitimate and which, spurious.

SKFS protects users, as well as the RP site, from such attacks by digitally signing every record within the database, and verifying the digital signature upon every read. SKFS's signing key is protected by a FIPS 140-2 Level-2 or Level-3 cryptographic hardware module when SKFS is operated within StrongKey’s Tellaro appliances. In a software-only SKFS deployment, the signing key is within a keystore with a password, and the RP’s FIDO administrator is responsible for protecting that signing key from being compromised.