Concepts

ZofToken

The ZofToken Solution is comprised of a ZofToken Instance (which is usually implemented with a single ZofToken Server but could include several) and any number of applications installed on on Android or Apple smartphones (either ZofToken Universal App or any app that integrate the ZofToken SDK).

A ZofToken (or simply a token) is composed of one User ID enrolled to a service (see definitions below) of a specific instance and contains the corresponding authentication secret.

ZofToken As A Service (ZaaS)

While we recommend that you do not outsource critical security protocols and therefore run a private ZofToken Server instance, for technical tests, enthusiasts or organizations whose business requirements are compatible with this model, we provide ZaaS as a way to quickly spin up a cloud-based instance.

Clients and users

A client is an organization who operates a ZofToken instance (either private or through ZaaS) while a user is somebody who has one or more enrolled tokens..

Services

Each ZofToken instance can handle any number of Services which can be used for many different objectives including grouping users, representing access to different assets or providing different configurations.

User IDs

Each User ID is a character string (with UTF-8 support) selected by the client for a particular user. Reasonable user IDs include existing usernames for specific assets, email addresses or passport numbers but there are no technical limitations to what can be used.

Enrollment

This is the process through which a client and a user agree on the use of a token to secure access to some asset. It has two phases: first the client creates a request on their ZofToken instance and provides the user with the enrollment data, and then the user sets up the token in their application (scanning a QR code, clicking on a deeplink or manually entering a one-time use code) depending on the mode of use that was selected.

PIN and Duress PIN

When ZofToken Universal App is being used, during the enrollment process the user has to select a 4-digit PIN to authorize any token operation.

If allowed by the service (as configured by the client), the user will optionally be able to select a different 4-digit PIN to indicate that the token operation is being performed under duress.

For existing apps or those which are designed during a ZofToken implementation (that integrate the ZofToken SDK), this process (which is critical to protect the authentication secret) can be performed in the same way by leveraging the functions available in the SDK or by other appropriate mechanisms (for example, using biometry).

Status

At any point during its lifecycle, a token will be in a specific status from the following list:

• Awaiting Enrollment – the token has been created on the ZofToken instance, but the user has not finished the enrollment process yet.
• Closed – the user has their token in a closed/deactivated state.
• Open – after the user opens/activates their token, and during a period of time configured in the service, the token will remain in the open state.
• Duress – (only possible if enabled by the service configuration) the last token operation performed by the user (either opening or closing) was performed using the duress function.
• Blocked – the token has been blocked either by failing to authenticate 3 consecutive times or manually by an instance administrator.

Authkeys

Each instance can have any number of authkeys that allow access to the API.

These keys can be configured to apply to specific services and/or user IDs and to allow administrative access (needed to generate new tokens or force changes in token status) or not (allowing access only to reading a token status).