Skip to main content
One of the main differences between de-registration and registration/authentication is that de-registration does not require the usual sequence of initializing and finalizing/validating the de-registration request, i.e. you do not have to finalize the de-registration request with the Hanko API. Depending on whether the userId associated with the devices you want to de-register exists or not, the entire de-registration operation is either OK or FAILED and therefore completed after the initialization step. Just as with registration and authentication though, you will receive a de-registration request in the form of a UAF protocol message upon initialization that must be passed to the FIDO UAF Client in order to de-register the respective credentials on the device.
  • Step 1: Retrieve a de-registration request
  • Step 2: Pass the de-registration request to the Hanko FIDO UAF Client
Hanko FIDO UAF Client de-registration flow

Sequence diagram for the UAF de-registration flow with the Hanko FIDO UAF Client for Android

Step 1: Retrieve a de-registration request

You can either de-register all authenticator devices for a user or you can de-register specific authenticator devices.

De-register all devices

To de-register all authenticator devices for a user, issue a POST request to the UAF endpoint ({API_URL}/v1/uaf/requests) of the Hanko API. You must provide the userId and the username of the user the authenticator devices are associated with as well as the appropriate operation type (DEREG).
The API should respond with a Hanko request, the status property indicating whether the de-registration process was successful (OK) or not (FAILED). It will also contain the request issued by the FIDO server which will be used in the next step.

De-register specific devices

To de-register specific authenticator devices for a user, issue a POST request to the UAF endpoint ({API_URL}/v1/uaf/requests) of the Hanko API. You must provide the userId and the username of the user the authenticator devices are associated with as well as the appropriate operation type (DEREG). To further specify the devices to de-register, include a comma-separated list of device ID strings under the deviceIds key in the request body. If you are unsure how to get the registered deviceIds of a user, you can always use the device management capabilities of the API to get the registered devices for a user, including the deviceId required for the de-registration process described above. When using IDs from the device list returned through this endpoint for de-registration, make sure you use only devices of the appropriate authenticator_type, i.e. FIDO_UAF.
The API should respond with a Hanko request. The status property indicates whether the de-registration process was successful (OK) or not (FAILED). It will also contain the request issued by the FIDO server which will be used in the next step.

Step 2: Pass the de-registration request to the Hanko FIDO UAF Client

Extract the request value from the Hanko request you retrieved in the previous step.Create a stringified representation of a JSON object with the following structure:
Use Android’s Intent mechanism to pass it to the Hanko FIDO UAF Client (<fido-uaf-request>). This will trigger a prompt for an authentication gesture. To retrieve the activity result, use the startActivityForResult API.
After the user accepted or denied the request by performing an authentication gesture, you can process the result using the onActivityResult API.
Extract the response (1) from the Intent data. The extracted value will be used in the next step to verify the authenticator response.