we just changed the way...how you manage your digital identity
The service that topID offers is a SaaS service. The heart of the topID technology consists of the API, which is hosted in the cloud. Three interfaces are available to access this API:
A patent has been applied for the method of logging in.
The JavaScript interface is the easiest to implement. You can opt for a complete processing of the login process via the telephone network, or a login process in which the exchange of the token takes place via the telephone network, and the exchange of the PIN or password via the computer network (LAN or WAN).
The environment in which the JavaScript interface is implemented ideally has a database of accounts that can be used. There are at least two required entities in the database:
If these fields do not exist (yet), they will have to be added to the database during implementation. If no database is available, you can of course also choose flat files with account details, or add a database for the login process. The best solution for the implementation can be found in consultation with topID.
For the JavaScript interface, a implementation set is available for PHP and - soon - Node. This implementation set also contains the necessary SQL tables and additional JavaScript libraries. Naturally, the final implementation depends on the environment of the customer. In addition to the API parameters (see below), the implementation set also offers the following settings:
| # | variable | validation | role |
|---|---|---|---|
| 1 | $_SESSION["ti_DefaultLanguageCodeEnvironment"] | ISO639-3 alpha3 | The placeholder for the customer's language setting |
| 2 | $_SESSION["ti_DefaultLanguageCode_topID"] | ISO639-3 alpha3 | This variable is set by the end-user in the opening screen of topID. It's the language topID will present it's feedback in. |
| 3 | $_SESSION["ti_NativeLanguageDescriptionsYN"] | Y, N | This variable determines if the language list in the opening screen of topID is showing the name of the language in their respective language, or if the default language setting of the environment will determine the language of the descriptions of the choosable languages. |
| 4 | $_SESSION["ti_NumberOfFactors"] | 1, 2 | Determines whether the login only uses the telephone you are using to dial in (= 1FA), or whether a PIN is required (= 2FA) |
| 5 | $_SESSION["ti_ChannelForPIN"]="web" | web, phone | Determines the channel for exchanging the PIN and/or registering new accounts. |
| 6 | $_SESSION["ti_NumberOfDigitsInPIN"] | 4, 6 | Determines if a PIN of four digits or a PIN of 6 digits is required. |
| 7 | $_SESSION["ti_HashedPINYN"] | Y, N | Determines if the PIN is hashed or not. |
| 8 | $_SESSION["ti_NumberOfPromptsForPIN"] | 1, 2 or 3 | "Determines how many times a wrong PIN can be entered before the account is blocked. The duration of the block is set with variable $_SESSION[""ti_TimeoutForBlockedAccountInSeconds""] (see 14)." |
| 9 | $_SESSION["ti_TimeoutInSeconds"] | Determines after how much elapsed time a unfinished login process will be cancelled. | |
| 10 | $_SESSION["ti_RedirectURIAPI"] | Determines how long an account will be blocked after entering too many wrong PINs. | |
| 11 | $_SESSION["ti_RedirectURIAPI"] | Directs the API to a URI where the result of the login is received and processed. | |
| 12 | $_SESSION["ti_RedirectURIResult"] | Shows the result of the login attempt. | |
| 13 | $_SESSION["ti_RedirectURIHomepage"] | Directs the user to the homepage after a succesful login. | |
| 14 | $_SESSION["ti_RedirectURINoAccess"] | Directs the user to this page after a unsuccesful login. Typically this will be the page on which the login process started. | |
| 15 | $_SESSION["ti_RedirectURINewAccount"] | Directs the user to the account registration page when the user is new and wants to register. | |
| 16 | $_SESSION["ti_MaximumNumberOfDevicesAllowed"] | 1, 2 or 3 | Determines how many devices are allowed. |
The SOAP and OpenId interfaces offer more integration possibilities with the existing infrastructure of the customer. Such implementations are by definition custom-made, and are realized in collaboration with topID.
Below are the available parameters of the API per interface.
When the API is deployed in web apps or websites, a few browser settings can throw a spanner in the works and prevent proper operation of topID. At the moment it mainly concerns two institutions:
When the browser is set to refuse cookies and prevent cross-site tracking, topID will not work. This is because the environment using topID must connect to the API in the cloud, via the topID server. After the exchange of the token via the telephone network, it is necessary to return to the environment from which the login procedure was started. The process therefore comprises at least 3 different domains: that of the customer, that of topID and that of the cloud supplier. If the customer chooses to link to a URI in another domain after a successful exchange, the counter is even set to 4. This cannot happen when cross-site tracking is blocked. After all, it is only possible to switch locations within the same domain.
With the use of different domains, the successful use of cookies is also necessary. These keep the necessary data that must ensure that asynchronous communication across different domains runs smoothly. By blocking cookies in the browser, topID will not be able to exchange this information and therefore cannot work.
The world of the internet is not standing still. It is therefore conceivable that with the emergence of new technologies, new settings will be added to the browser, which could again throw a spanner in the works. This is the place to see which browser settings continue to guarantee topID compatibility.
Below are the steps required to make these settings correctly in the most used browsers on the most used operating systems.
Verify Settings iPhone Safari