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.

  1. Install the SDK on your server (e.g. through NPM). You can also choose to deploy the server-sdk as a (containerized) app that you interact with through an API.
  2. Use the SDK to perform a one time setup to register
    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 and/or
    A verifier is a role a company can play to verify presentations shared by subjects (users). A verifier can also make requests for presentations and send them to subjects.
    + More...
    Example: Hooli FinTech sends Richard a request for (a presentation of) a KYC verification credential from ACME Bank. When Richard shares the presentation, Hooli verifies it.
    Components: A verifier requests and verifies presentations using the Server SDK.
    verifiers. Store the private keys that the SDK returns securely in your database associated with the registered entities.

If acting as an Issuer#

  1. Create an endpoint adhering to the OpenApi specification to receive signed Subject credential requests from our Identity Engine wallet. This endpoint also handles receiving user DID data from our Identity Engine cloud.

If acting as a Verifier#

  1. Create an interface the Web SDK can use to interact with the Server SDK. For example so a presentation request created by the Server SDK can be displayed on the client.
  2. Create an endpoint adhering to the OpenApi specification for receiving encrypted Presentation data from our Identity Engine cloud.

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
A DID (or decentralized identifier) identifies a participant in the Unum ID ecosystem. A participant is an issuer, subject, or verifier.
+ More...
Example: ACME Bank is identified by two DIDs, one for acting as an issuer and another for acting as a verifier. Richard, an ACME subject (user), is identified by one DID. Hooli FinTech, which acts as a verifier, is identified by one DID.
Components: The Server SDK returns DIDs for issuers and verifiers, and the Mobile SDK returns DIDs for subjects.
DID. 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.

Versioning Strategy#

The Unum ID Server, Mobile, and Web SDK major versions correspond to one another. It is recommended to keep the Web and Server SDK versions aligned with one another for the best experience. For example, if using version 3.1.0 of the Server SDK it is advised to use version 3.x.x of the Web SDK. By nature of the network, keeping Holder SDK version alignment with the Server SDK is practically impossible. However, we have a solution.

Each major version of the Server and Holder SDKs are mostly backwards compatible with older versions of one another. If performing the role of an Issuer all SDK versions will be backwards compatible. If performing the role of Verifier presentation verification is often the functionality that is not backwards compatible. In order to support presentation verification from variable Holder SDKs one will need to leverage all Server SDK versions that they need to support. This is akin to normal mobile application versioning strategies of the server always supporting a version greater than or equal to the mobile version.

note

Upon leveraging or testing a new Server SDK major version end to end we the version information corresponding to your

A verifier is a role a company can play to verify presentations shared by subjects (users). A verifier can also make requests for presentations and send them to subjects.
+ More...
Example: Hooli FinTech sends Richard a request for (a presentation of) a KYC verification credential from ACME Bank. When Richard shares the presentation, Hooli verifies it.
Components: A verifier requests and verifies presentations using the Server SDK.
verifier needs to be updated so we know how to route
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.
presentations to the version of your application with corresponding Server SDK version. This information is originally provided during registration.

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.