Skip to main content

FIDO UAF Credential Deregistration

Description​

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.

Prerequisites​

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

Example​

The numbers in the description below correspond with the numbers in the next figure.

  1. The user no longer wishes to use an application. She initiates the deregistration procedure to remove her credentials.
  2. The mobile application sends a request to trigger the in-band FIDO authentication.
  3. The user authenticates. Nevis allows the mobile client application to perform a deregistration.
  4. The mobile application sends a request to Nevis to perform the deregistration.
  5. 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.
  6. The mobile application removes the FIDO credentials.
info

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.

danger

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.

For details, see the nevisFIDO Reference Guide, sections Registration Response Serviceand Dispatch Target Service.

In-Band Deregistration

Technical Flow​

info

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.

title="In-Band Deregistration Flow"

The numbers in the list correlate with the step numbers in the previous figure.

  1. The relying party mobile application authenticates with FIDO UAF credentials.

    Endpoint: https://<nevisProxy-host>:<nevisProxy-port>/auth/fidouaf

    References:

  2. The relying party mobile application sends a GetUAFRequest to 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.

    The GetUAFRequest must be created with the operation set to "Dereg".

    info

    In case of a deregistration, the GetUAFRequest has 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".

    Endpoint: https://<nevisProxy-host>:<nevisProxy-port>/nevisfido/uaf/1.1/request/deregistration

    info

    This endpoint is defined in nevisProxy and maps to the Deregistration Request Service endpoint.

    References:

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

    The userId is delegated to ensure that the generated authorization header is correctly formatted.

  4. nevisProxy forwards the GetUAFRequest to nevisFIDO.

    Endpoint: https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/uaf/1.1/request/deregistration

    References:

  5. 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 extId or the loginId in nevisIDM - this is configurable.

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

  7. nevisFIDO returns the ReturnUAFRequest containing the DeregistrationRequest.

    The generated DeregistrationRequest always contains all deregistered credentials as separated entries.

    nevisProxy forwards the ReturnUAFRequest to 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.

    References:

Configuration Snippets​

You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.