Basic terms and definitios used througout the ZofToken documentation
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.
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.
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..
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.
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.
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.
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).
At any point during its lifecycle, a token will be in a specific status from the following list:
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).