Skip to main content

Deployment Overview

This section provides a brief overview of how your company can deploy Unum ID tech. For full technical details, see the documentation for each component:

Process#

Each Unum ID component is simple to install and use. Your development team should be able to try the platform in a matter of hours and complete an integration suitable for a pilot in a few days. We provide dedicated engineering support to make the process as easy as possible.

Simulated Deployment#

For pilots, we can also provide a ​simulated deployment, which allows you to try Unum ID technology with zero integration work. We host all the components for you and provide a dedicated mobile app and website with your branding. Your testers can then try the platform by simply installing the app and using the website.

This is a great way to build the business case for Unum ID before progressing to a full deployment. Please ​contact sales​ for more.

Installing Components#

When you register as an Unum ID customer, we send you API keys for each component.

Mobile SDK#

See full documentation here.

  1. Add the SDK to your mobile app (e.g. through Maven/CocoaPods).
  2. Publish an update to the app stores.
  3. Store the user identifier the SDK returns in your database.

As noted in the ​FAQ​, you can add Unum ID on top of your existing account system. To do so, simply initialize the Mobile SDK after a user logs into their account. You can later transition away from the account system to fully eliminate passwords.

The Mobile SDK works entirely behind the scenes, benefitting users without intruding on the UI/UX of your app. The only components exposed to the user are system alerts and a QR code scanner, which you can trigger from anywhere in the app (e.g. with a Scan button).

Server SDK#

See full documentation here.

You can also choose to deploy this as a (containerized) app that you interact with through an API.

  1. Install the SDK on your server (e.g. through NPM).
  2. Store the private keys that the SDK returns securely in your database.
  3. Create an interface the Web SDK can use to interact with the Server SDK.
  4. Create an endpoint to receive encrypted data from our Identity Engine cloud.

For steps (3) and (4), we provide OpenAPI specifications and reference implementations to make this easy.

Using the Server SDK is straightforward. To issue (send) a

A credential is a collection of data about a person. It's issued by a company (i.e. created and sent to a user) and stored in the company's app, on that user's device.
+ More...
Example: ACME Bank issues a KYC verification credential to Richard (an ACME user). This includes Richard's contact information and account numbers, as well as a level of confidence in the accuracy of the data.
Components: A company issues credentials using the Server SDK, and an app stores credentials using the Mobile SDK.
credential to a user, you input identity data and the user’s identifier. And to
A request (or presentation request) is a request for a presentation. It's sent by a company to a user, who chooses whether to share a presentation in response.
+ More...
Example: Hooli FinTech sends Richard a request for (a presentation of) a KYC verification credential from ACME Bank.
Components: A company creates requests using the Server SDK and routes them to users using the Web SDK. A user's app responds to requests using the Mobile SDK.
request a
A presentation is a set of one or more credentials. It's shared with (or presented to) a company by a user.
+ More...
Example: Richard shares a presentation of a KYC verification credential (which ACME Bank issued to him) with Hooli FinTech.
Components: A user's app shares (or presents) presentations using the Mobile SDK, and a company verifies presentations using the Server SDK.
presentation from a user, you input the type of credential and acceptable
An issuer is a role a company can play to issue credentials to subjects (users). An issuer also change credential statuses, for example to revoke credentials.
+ More...
Example: ACME Bank issues a KYC verification credential to Richard (an ACME user). It later revokes that credential and issues a new one to Richard to update his information.
Components: An issuer issues credentials and changes credential statuses using the Server SDK.
issuers. The SDK handles the rest.

Web SDK#

See full documentation here.

  1. Add the SDK to your web client (e.g. through NPM).
  2. Point the Web SDK at the Server SDK interface you created in step (3) above.
  3. Define a redirect for when a
    A presentation is a set of one or more credentials. It's shared with (or presented to) a company by a user.
    + More...
    Example: Richard shares a presentation of a KYC verification credential (which ACME Bank issued to him) with Hooli FinTech.
    Components: A user's app shares (or presents) presentations using the Mobile SDK, and a company verifies presentations using the Server SDK.
    presentation is verified (e.g. granting the user access).

Using the Web SDK is simple. Just call the Server SDK to create

A request (or presentation request) is a request for a presentation. It's sent by a company to a user, who chooses whether to share a presentation in response.
+ More...
Example: Hooli FinTech sends Richard a request for (a presentation of) a KYC verification credential from ACME Bank.
Components: A company creates requests using the Server SDK and routes them to users using the Web SDK. A user's app responds to requests using the Mobile SDK.
requests for presentations from users. The Web SDK takes care of everything else — the user interface, fallback options, error handling, etc.

FAQ#

Do we have to replace our account system?

No. Unum ID can sit on top of your existing account system, facilitating a gradual transition away from passwords. You don’t have to eliminate them right away, or ever if you prefer.

We recommend first using Unum ID as a second step in the authentication process, on top of your existing account system. Then, you can gradually replace that system entirely to fully eliminate passwords and remove the weak link.


Are there setup steps for users?

No, for users everything works automatically, behind the scenes. When you set up Unum ID, you add our Mobile SDK to your app and publish an update to the app store. The next time the user opens the app, they’ll have all the functionality Unum ID provides without having to do anything. It’s just like a normal feature update.


What if a user loses their phone?

Not a problem. The user’s app is backed up, and they can remotely deactivate their lost phone, just like they can cancel a credit card.

The default backup is to the user’s iCloud (on iOS) or Google Drive (on Android) account, so when they get a new phone everything will work like before. We also provide an easy way for you to store a backup on the user’s behalf.

Unum ID requires that the user has a device biometric and passcode set up. Lost phones that have these enabled are extremely secure. (Even the FBI couldn’t break into an iPhone.) But for extra protection, we provide a way for the user to remotely deactivate the app on the lost phone, making it useless even if an attacker breaks through the biometric. And for ultimate protection, the user can choose to remotely erase their device.


What if a user has multiple phones?

They can use all of them and keep them synchronized.