Skip to main content

Mobile SDK - Flutter

This is a cross-platform SDK that allows a host app to receive and store

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.
credentials, receive
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, and share
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. It supports both Android and iOS applications built using the Flutter framework.

Before you begin: You need to be registered as Unum ID customer, and you need to register at least one

A holder app is an Unum ID enabled mobile app. See also: holder.
+ More...
Example: ACME Bank adds Unum ID technology to its mobile app, making it a holder app.
Components: A holder app is one using the Mobile SDK.
holder app. (You can register zero to many, depending on your use case.) You'll receive a holder app API key to use with this SDK.

Overview#

Minimum Requirements#

  • Android 6.0 (Marshmallow) and above
  • iOS 13 and above
  • English language (internationalization coming soon)

Required Permissions#

  • Camera: requested when you show the QR code scanner
  • Biometrics/Passcode: requested when you call initialize()

Permissions and any permission rational messages should be updated in the individual native sections of the host application.

Setup#

Installation#

Install the flutter plugin by adding it to your pubspec.yaml file.

dependencies:
unumidflutter:
git:
url: git@github.com:UnumID/unumid-sdk-flutter.git

Usage#

SDK Initialization#

This function initializes the Unum ID SDK, allowing the host app to use it. It must be called before any other SDK functionality can be used. In most cases, it should be called when the application loads/comes to the foreground. Once onSuccess is returned, the developer will then be able to retrieve the saved did.

import 'package:unumidflutter/unumidflutter.dart';
Future<void> _sdkInit() async {
final prefs = await SharedPreferences.getInstance();
var userId = currentUserID;
var did = currentUserDid; // can be empty
var customerId = "YourCustomerId";
var apiKey = "YourApiKey";
var results = await Unumidflutter.initialize(userId, did, customerId, apiKey);
// returned results will be the user DID
print("Result: " + results);
if (results.toString().isNotEmpty) {
// store DID for future reference
}
}
_sdkInit();

SDK handle deeplink#

Used to manually handle a link.

import 'package:unumidflutter/unumidflutter.dart';
Unumidflutter.handleLink("deepLinkUri");

SDK QR Code Scanner#

Used to scan a QR code using the build in scanner. If you would like to use a custom scanner, simple send the received url to the handleLink api.

import 'package:unumidflutter/unumidflutter.dart';
Unumidflutter.scanQrCode();

SDK Logging#

Turn on SDK Logging

import 'package:unumidflutter/unumidflutter.dart';
Unumidflutter.turnOnLogging();

Handling Multiple Users#

Each user is identified by some user ID in your system and by a

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 in the Unum ID ecosystem. You simply need to store an association between each user ID and DID. That way, when your host app has a particular user ID (for example once a user is logged into your existing account system), it can pass the corresponding DID to the SDK.

If you don't have existing user IDs, you could use the DIDs themselves as user IDs. However, we recommend using separate identifiers (internal to your company), to distinguish them from DIDs, which are global to the Unum ID ecosystem.

note

The technical details of DIDs are not relevant to deploying or using Unum ID. You can think of DIDs as identifiers in the normal sense โ€” unique, random strings of characters like UUIDs.

When you initialize the SDK, you can optionally include a DID.

  • Don't include a DID for a user who's new to the SDK. The SDK will generate a new one that you should store, associated with the user ID in your system.
  • Do include a DID for a user who returns to the SDK. The SDK will use this DID to access the correct stored data for that user.
important

DIDs are the only identifiers the SDK understands, so it relies entirely on the host app to pass the correct one.

For example, suppose Users 1 and 2 are associated with DIDs 1 and 2, respectively. If User 1 is using the host app, but the app passes DID 2 to the SDK, the SDK will give User 1 access to to User 2's data.

Example Flow#

  1. New User 1 logs into host app.
    • SDK is initialized with no DID.
    • SDK returns newly generated DID 1.
    • Host app stores DID 1 and associates it with User 1.
  2. New User 2 logs into host app.
    • SDK is initialized with no DID.
    • SDK returns newly generated DID 2.
    • Host app stores DID 2 and associates it with User 2.
  3. Returning User 1 logs into host app.
    • Host app retrieves DID 1 and includes it in SDK initialization.
    • SDK recognizes this is a returning user and does not generate a new DID.