Troubleshooting

The aim of this document is to help end-users overcome occasional challenges by themselves, reducing support needs. This page helps you to independently troubleshoot issues related to your Access App and mobile devices. Going through the following checks will assist your end-users in overcoming the most frequent hurdles during registration.

Required Device Passcode

The app requires a device passcode to be set. In case the device passcode is removed, all existing accounts and registrations are removed.

Not receiving push notifications

Several things can lead to the user not receiving push notifications. We recommend the following steps before submitting a request via the Nevis portal.

1. Ask the user to simply open the app. This will lead to the push token being updated in the backend. If the user hasn't used the app for some time, the push token might have been invalidated in the meantime.
2. Ask the user to check whether (s)he has enabled push notifications for the app. In case the user opted out (retracted the permissions), this will be indicated in the backend. The generic dispatch target credential attribute fidouaf_target will have the value user-disabled.
3. For iOS, if you are managing your own Google Firebase project, verify that the APNs key is correct and valid by checking the TeamID and KeyID

Nevis Authentication Cloud

The Nevis Authentication Cloud will soon allow administrative users to see if a user disabled push.

Losing the push notification

In case the user swipes away the push notification, it is gone and cannot be restored. The user must start a new authentication or transaction signing operation.

info

Future app versions will allow a user to "fetch" such lost push messages.

Android Face Authentication

Depending on the ordered Access App, face authentication may not be available due to most Android face authenticators offered by vendors not being considered secure enough. Refer to allow class 2 biometric sensors.

Android Profiles

As opposed to iOS, Android supports OS-level profiles (for example a work profile). Depending on the manufacturer, the Access App may not work correctly with certain profiles. See the known issues section. In case the app is installed in both profiles, the user has to make sure (s)he installed the app under the correct profile and performed the registration in the correct app.

App Performance

Some users may experience app performance degradation specifically with older Android and iPhone models. This cannot be mitigated but may require explanation.

Two of the reasons why the access app on older device may not feel as responsive as newer devices are:

1. The Access App performs a lot of cryptographic calculations which require comparatively intensive computation.
2. The secure nature of the app preventing attacks and abuse require additional computational checks which older devices take additional time to calculate when compared to an insecure / non-cryptographic app.

Additional factors directly related to the device can play a role as well:

• Low battery: CPU power and performance is reduced when the battery is low to extend the durability.
• Old battery: CPU power and performance is reduced for old batteries to extend the durability. "Old batteries" is not directly related to the phone age itself but rather the loading cycles and battery health.

Lost phone recovery

If the user loses the device, there is no recovery option available. However the chances of another person being able to use the phone to authenticate is extremely low due to all the security measures being in place such as:

• A required device passcode
• PIN brute force attack prevention
• Biometric authenticators

To have the highest level of security, we recommend specifying and integrating a flow for this scenario, which will allow the user to easily report a lost or stolen device. This flow should delete the UAF and generic dispatch target credentials associated with the user.

Migration to new phone

The Access App does not support migrating accounts / registered authentication methods to a new device / new app installation. A new registration is required.

info

Future app versions will offer a migration option.

Understanding the nevisIDM credentials

Mobile authentication credentials can be confusing to grasp initially. The following information is important to gain a basic understanding:

• The Generic Dispatch Target credential representing the installed app on his/her physical device. It is used for out-of-band message transmission and device information management.
• The UAF credential represents the authenticator .
• There is a 1:m relationship for a single user between the generic dispatch target and the UAF credentials.
  • A user will always have one generic credential and one or more UAF credentials.
• If the user installs another app containing our SDK, it will result in a new generic credential reflecting that app installation.
• A user can register every authenticator type available exactly once per app (e.g. it is not possible to register two PIN authenticators on the same app).
• Not all authenticators available in the SDK are available to be used in the Access App. An example is the device passcode authenticator which is only available in the SDK but could be made available in the Access App if customer demand exists.
• The Access App and SDK offer multi-account and multi-backend functionality. A user can register multiple “accounts” on the same backend which is reflected in nevisIDM as a separate user having separate credentials. The user can also register multiple accounts on multiple backends, every account is bound to the backend where they registered.
  • Multiple user accounts on the same backend will result in every nevisIDM user having its own generic dispatch target entry with a unique extId. However, the other information is exactly the same. From the apps perspective it is still a single app installation on a single device. This means that multiple users in nevisIDM can actually have generic dispatch target credentials with the same deviceId and key material.

Mobile Authentication Credential Attributes

It is useful to know some attributes stored in the nevisIDM credentials related to mobile authentication. You should generally never make manual changes in nevisIDM to any of these credentials or their attributes.

UAF Credential

• Attestation ID: Identifies the authentication method
• Key ID: Randomly generated value representing the authenticator instance. Combined with the Attestation ID it is a guaranteed unique value.
• Dispatch Target ExtId: The credential identifier for the associated generic dispatch target. This attribute ensures the 1:m relationship.
• Last Change: Timestamp of the last (successful) authentication or transaction confirmation using this authenticator.
• Public Key: The actual public key generated by the mobile app used to sign the authentication or transaction confirmation assertion presented by the backend.

Generic Dispatch Target Credential

• Identification: Backend generated identifier which is forwarded to the Access App. This identifier is used by the Access App to update the credential as the Credential ID is considered a backend-internal attribute.
• fidouaf_name: Users can rename their device in the Access App. This is useful when a user has multiple devices with the same app installed. The name must be unique in the context of a user.
• fidouaf_target: This attribute is only used for push notifications, it is updated every time the app is started. Possible values this attribute can take are:
  • empty
    • no push support in the ordered Access App
    • the push token could not be obtained by the Access App, this can indicate an issue with the Firebase push service
  • user-disabled
    • The user did not grant push permissions to the app or retracted push permissions.
  • Random string
    • The firebase push token
• fidouaf_encryption_key: The public key used for channel end-to-end encryption.
• fidouaf_signature_key: The public key used to grant the Access App access to JWS protected backend APIs without requiring the user to authenticate himself/herself.
• fidouaf_device_id: The device identifier generated by the Access App. This identifier is intended to stay consistent during the lifetime of the device in most normal scenarios.
  • If the end user uninstalls and re-installs the Access App, the device identifier remains the same.
  • If the user registers multiple accounts in the Access App, every user in nevisIDM will have a generic dispatch target with the same deviceId.
• fidouaf_user_agent Proprietary HTTP user agent used by the Access App. This attribute contains useful information regarding the app and SDK version as well as the device model.

Opening a Nevis support ticket

For opening a Nevis support ticket, have a look at the bug reporting guidelines which outlines what information we need in order to help you.

Supplementary material

Additional information which may be useful for support is located in:

• FAQ
• Known Issues
• Known Limitations