Deregistration
Deregistration removes the FIDO UAF credentials of a registered mobile device from nevisIDM. The mobile application removes the credentials from the device after it processes the deregistration request. It is the counterpart of Registration.
The services are called by the mobile application, typically when the user deletes an account in the app. Configure them with the Mobile Deregistration Service pattern.
For the protocol flow, see FIDO UAF Credential Deregistration.
Deregistration removes only the FIDO UAF credentials. The Generic credential that makes the device a dispatch target is left in place, so the backend can still dispatch push notifications to a device that can no longer authenticate.
To clean up both, correlate them through the deviceId attribute. The dispatch target and the FIDO UAF credential created on the same device carry the same value, so removing every credential with a given deviceId removes the device completely. See Dispatch Target Management.
Configuring the Mobile Deregistration Service
Add a Mobile Deregistration Service pattern to your project and fill in its fields:
- Virtual Host(s): assign the virtual host on which the protected services are exposed.
- Authentication Realm: assign an In-band Mobile Authentication Realm pattern. Only that realm type is supported here.
- Application Access Token: assign a Nevis SecToken pattern. Assign the same pattern to the Application Access Tokens field of the realm, otherwise nevisFIDO cannot verify who is calling.
- nevisFIDO: assign the nevisFIDO UAF Instance pattern that provides the deregistration services.
Services exposed
The pattern exposes the following paths on the assigned virtual host:
| Path | Purpose |
|---|---|
/nevisfido/uaf/1.1/request/deregistration/ | The deregistration request service. This is the one path that requires an authenticated caller. |
/nevisfido/uaf/1.1/facets | The facets of the mobile application. |
/nevisfido/token/dispatch/targets/* | Dispatch target management. |
/nevisfido/devices/credentials/* | Credential queries for the device. |
The authentication endpoint itself, /auth/fidouaf, is not exposed by this pattern. It comes from the assigned In-band Mobile Authentication Realm.
Why the realm is required
The deregistration request service removes credentials without asking the device or the user again, so only the authenticated owner of those credentials may reach it. That is what the realm provides.
The mobile application first authenticates in-band at /auth/fidouaf, then calls the deregistration request service with the session it obtained. nevisProxy adds the SecToken and the user ID to the forwarded request, and nevisFIDO verifies the SecToken signature before it removes anything. This is why the same Nevis SecToken pattern has to be assigned in both patterns.
For the in-band authentication that precedes deregistration, see In-Band Authentication and Authentication.
Deregistration from the Nevis Access App
The Access App distinguishes removing a single account from resetting the whole app. The two differ in what is deleted locally and what is reported to the backend. See Account removal versus app reset.
Two further situations remove registrations without an explicit deregistration call, and both surprise users rather than integrators:
- Removing the device passcode deletes all accounts and registrations on the device. See Troubleshooting.
- Changing the biometric configuration of the operating system can invalidate a registered authenticator. See Removing authenticators on new OS biometrics.
The Access App supports the deregistration operation on all of its channels, but the Nevis backend products do not implement it for them. Deregistration is therefore an in-band operation. See Channels.