FIDO UAF Credential Deregistration
A user may want to remove existing FIDO UAF credentials for several reasons. In the FIDO UAF context, removing existing FIDO UAF credentials is called "Deregistration". The credentials must be removed from both the user's device and the FIDO server. For more information, see chapter FIDO UAF (Universal Authentication Framework) - Deregistration.
- The user's client application that is deregistering the credentials must have FIDO capabilities. It must contain an embedded FIDO client with access to one or several FIDO authenticators.
- The user has already existing credentials, such as a password in nevisIDM, that can be used to authenticate.
- Nevis should be configured such that only authenticated clients can deregister FIDO UAF credentials. In this case, the legacy credentials are used to authenticate.
- The user has already registered FIDO credentials (which he now wants to remove).
The numbers in the description below correspond with the numbers in the next figure.
- The user no longer wishes to use an application. She initiates the deregistration procedure to remove her credentials.
- The mobile application sends a request to trigger the in-band FIDO authentication.
- The user authenticates. Nevis allows the mobile client application to perform a deregistration.
- The mobile application sends a request to Nevis to perform the deregistration.
- The FIDO credentials are removed from their storage on the Nevis side. Nevis informs the mobile application which FIDO credentials must be removed on the mobile application side.
- The mobile application removes the FIDO credentials.
Instead of the in-band FIDO authentication, it is also possible to use legacy nevisIDM credentials to authenticate. The performance of a Deregistration operation in nevisFIDO requires an authentication with the username.
The Deregistration operation described in this section only affects the registered FIDO UAF credentials. The corresponding registered dispatch targets will stay in place and are not removed. Refer to chapter Dispatch Target Management for additional details.
To find the dispatch target that is associated with a FIDO UAF credential, you can use the deviceId attribute. The dispatch targets and FIDO UAF credentials that have the same deviceIdvalue are stored on the same device. So if you want to remove all dispatch targets and corresponding FIDO UAF credentials on a given device, remove all elements with the same deviceId.
The technical flow in the next figure explains the component interaction in detail. The step numbers in the figure do not correlate with the simplified example above.
The numbers in the list correlate with the step numbers in the previous figure.
The relying party mobile application authenticates with FIDO UAF credentials.
The relying party mobile application sends a
GetUAFRequestto the Deregistration Request Service endpoint.
In this step, the mobile client accesses the same endpoint as in step 1. But now the client possesses an existing authentication to do so.
GetUAFRequestmust be created with the operation set to "Dereg".info
In case of a deregistration, the
GetUAFRequesthas special context extensions that enable several different behaviors of the endpoint. For details and the use cases it supports, have a look at the nevisFIDO Reference Guide, chapter "Context".
This endpoint is defined in nevisProxy and maps to the Deregistration Request Service endpoint.
nevisProxy includes the SecToken and the UserId into the forwarded request.
The inclusion of the SecToken ensures that nevisFIDO will receive the user information in a secure way. It also helps to verify that an authentication has already been successfully completed. This information is necessary to initiate the FIDO deregistration.
userIdis delegated to ensure that the generated authorization header is correctly formatted.
nevisProxy forwards the GetUAFRequest to nevisFIDO.
The signature of the SecToken is verified by nevisFIDO, to ensure that a previous authentication happened.
nevisFIDO extracts the username from the context of the
GetUAFRequest. The username can be the user's
loginIdin nevisIDM - this is configurable.
nevisFIDO removes the credentials from nevisIDM.
Based on the context provided in the
GetUAFRequest, nevisFIDO might remove more than one (even all) credentials associated with the username in nevisIDM.danger
Once the endpoint is successfully called, the credentials are removed without further consulting the mobile device or with the user.
nevisFIDO returns the
DeregistrationRequestalways contains all deregistered credentials as separated entries.
nevisProxy forwards the
ReturnUAFRequestto the relying party mobile application.danger
After receiving the
DeregistrationRequest, it is crucial that the FIDO client removes all corresponding registered credentials. If the credentials are not removed, they may remain on the device indefinitely.
You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.