Contract Registration

The TrustFactor enrollment process enables an application user to securely enroll into TrustFactor for transaction authentication. The process involves the user interacting with the application, TrustFactor SDK/API and the TrustFactor mobile application.

Key Steps

The user initiates the process by choosing to enroll in TrustFactor from within the application.
The application, utilizing TrustFactor's SDK, checks if the user is already enrolled.
If the user is not already enrolled, the application requests a registration QR Code or deeplink from TrustFactor's API.
Optionally, the application requires the user to share a precise location in order to enroll. The requirement is carried by the QR Code or deeplink itself.
The user scans the QR Code or taps the deeplink using the TrustFactor mobile application.
The TrustFactor mobile app generates a key-pair and shares the public key with TrustFactor's cloud services.
Upon receiving the public key, TrustFactor's services call the registerCallbackURL to notify the application.
If the application responds with a successful HTTP code, TrustFactor confirms the successful enrollment to the user via the mobile app and the application.

The user enrollment flow consists in two stages:

A - Registration Code Creation

Assumptions:

User is already authenticated in Internet Banking / App Client

During this process the client's application asks TrustFactor for a new registration code in order to enroll a new user with TrustFactor.
In order to create the said registration code the application must specify an Username and an UserID which doesn't need to be a legal name and/or an internal user ID (ie: bank account number).

B - Contract Registration

Assumptions:

User already has TF App opened and authenticated

TF Agent will generate a cryptographic key pair and share it's public key after scanning the QR Code which contains a Registration Code Unique ID. If the registration is successful the Username, User ID, Device ID and Contract Public Key will be stored on TrustFactor database. TrustFactor will also send a callback to the application notifying it of a new contract enrollment containing the Contract Details and Device Details.

Requiring a precise location at enrollment

An application can require the user to share a precise location before a contract is enrolled. The requirement is set per registration code, so the same application can require it for some enrollments and not for others.

When no location is shared

The requirement is enforced when the contract is registered. If the code requires a precise location and the TF App registers without one, the registration is refused with HTTP 400 and the error code E_400100004 - A precise location is required to register this contract.

caution

The registration code is consumed before this check runs, exactly like the pre-existing "contract already exists" rejection. A refused registration needs a fresh registration code in order to retry. A well-behaved TF Agent never reaches this point, because the QR Code already told it that a location was needed.

Two different locations

The position shared with the registration is not the device's last known location. TrustFactor also keeps the last position a device shared out of band, which never expires and may have come from GPS, WiFi triangulation, the carrier or an IP lookup. A cached position never satisfies this requirement, only a fresh fix shared with the registration itself does. Both are stored and the Backoffice shows them separately.