light-mode-image
Learn
SDKs

SDK Tethering

Learn how MATTR Verifier SDKs are tethered to a MATTR VII tenant through Verifier Application configuration, enabling operational insights and licensing.

SDK Tethering ties each SDK/app instance to a MATTR VII tenant. Tethering establishes a trust relationship between your mobile application and the MATTR VII tenant, enabling the following capabilities:

  • Operational insights: View details about registered and active app instances directly from your tenant.
  • Licensing: On first initialization, the SDK registers the app instance with your tenant and obtains a license. The majority of the SDK's APIs require a valid license to operate.
  • Remote management channel: SDK Tethering establishes a channel that we expect to extend in the future with capabilities such as remote syncing of trusted issuer lists and eventing.

SDK Tethering is available from the following SDK versions:

  • iOS Verifier SDK: 6.0.0
  • Android Verifier SDK: 7.0.0

SDK Tethering applies to the native iOS and Android Verifier SDKs. The React Native Verifier SDK is not tethered: it does not register app instances or require a platform configuration at initialization. For React Native, a platformConfiguration (tenant host only) is needed solely for remote mobile (app-to-app) verification.

SDK Tethering is required for the native iOS and Android Verifier SDKs. You enable it by providing a platform configuration when initializing the SDK. This builds on an existing requirement: remote mobile (app-to-app) verification already required a platform configuration so the SDK could reach your MATTR VII tenant to handle backend verification. That platform configuration is now mandatory for all native iOS and Android initializations and additionally drives SDK Tethering. Initializing the native iOS or Android Verifier SDK without a platform configuration is no longer supported. The React Native Verifier SDK is not tethered and can still initialize without a platform configuration for in-person verification (see the callout above).

How it works

The tethering process involves three steps:

  1. Configure a Verifier Application on your MATTR VII tenant: You register your mobile app by creating a Verifier Application, identified by the bundle identifier (iOS) or the package fingerprint (Android).
  2. Initialize the SDK with your tenant details: When you initialize the SDK in your app, you pass the details of the MATTR VII tenant and the Verifier Application you configured on it.
  3. Automatic communication: Once initialized, instances of your app will automatically communicate with the configured MATTR VII tenant and retrieve the required tokens to operate and make requests to the tenant when required.

Token validity and offline use

The tokens issued during this process have configurable validity periods controlled by the maxTimeOfflineInSecs field on your Verifier Application configuration. This means your app can function without internet connectivity to meet different use cases:

  • Minimum: 1 day (86400 seconds)
  • Maximum: 30 days (2592000 seconds)
  • Default: 7 days (604800 seconds)

When the license token expires, the SDK must reconnect to the MATTR VII tenant to renew it. Network access is required when registration or renewal is performed.

Configuring SDK Tethering

Configure Verifier Applications

SDK Tethering is required for the native iOS and Android Verifier SDKs. To enable it, create a Verifier Application on your MATTR VII tenant for each platform target (iOS and Android). This is a one-time setup process that registers your app with the tenant and allows app instances to obtain the necessary tokens for authentication and operation. The React Native Verifier SDK is not tethered — see the React Native tab below for when a Verifier Application is needed.

Make a request of the following structure to create an iOS Verifier Application configuration on your MATTR VII tenant:

Request
POST /v2/presentations/applications
Request body
{
    "name": "My iOS Verifier Application",
    "type": "ios",
    "bundleId": "com.yourcompany.verifierapp",
    "teamId": "YOUR_APPLE_TEAM_ID",
    "maxTimeOfflineInSecs": 864000,
    "appAttest": {
        "required": true,
        "environment": "production"
    }
}
  • name: A unique name to identify this Verifier Application.
  • type: Must be ios.
  • bundleId: The Bundle ID of your iOS app (must match your Xcode project configuration).
  • teamId: Your Apple Developer Team ID.
  • maxTimeOfflineInSecs: Maximum number of seconds the SDK can operate offline before requiring a new license token. Must be between 1 day (86400) and 30 days (2592000). Defaults to 7 days (604800).
  • appAttest: App Attest configuration for the iOS verifier application:
    • required: When true, the app instance must provide a valid App Attest attestation during registration and token renewal. When false, the app can fall back to assertion-only authentication. See Attestation vs Assertion for more details.
    • environment: The App Attest environment (development or production). Apple recommends using development for testing and production for distribution builds.

A successful response returns a 201 status code with the created Verifier Application:

Response
{
    "id": "1ef1f867-20b4-48ea-aec1-bea7aff4964c", 
    "name": "My iOS Verifier Application",
    "type": "ios",
    "bundleId": "com.yourcompany.verifierapp",
    "teamId": "YOUR_APPLE_TEAM_ID",
    "maxTimeOfflineInSecs": 864000,
    "appAttest": {
        "required": true,
        "environment": "production"
    }
}
  • id: A unique identifier for the Verifier Application (generated by the tenant). You must use this value when initializing the SDK so that it can correctly identify and authenticate your application.

Make a request of the following structure to create an Android Verifier Application configuration on your MATTR VII tenant:

Request
POST /v2/presentations/applications
Request body
{
    "name": "My Android Verifier Application",
    "type": "android",
    "packageName": "com.yourcompany.verifierapp",
    "packageSigningCertificateThumbprints": [
        "1232584B6F6A892D356899FB9576C5F226A179E6199F2B7A1D837B5C234C5A8E"
    ],
    "maxTimeOfflineInSecs": 864000,
    "keyAttestation": {
        "required": true
    }
}
  • name: A unique name to identify this Verifier Application.
  • type: Must be android.
  • packageName: The package name of your Android application.
  • packageSigningCertificateThumbprints: SHA-256 hex-encoded fingerprints of the signing key certificates used to sign your APK or app bundle. This ensures the tenant only accepts requests from known and trusted applications. Refer to Android app signing for more information.
  • maxTimeOfflineInSecs: Maximum number of seconds the SDK can operate offline before requiring a new license token. Must be between 1 day (86400) and 30 days (2592000). Defaults to 7 days (604800).
  • keyAttestation: Key Attestation configuration for the Android verifier application:
    • required: When true, the app instance must provide a valid Key Attestation during registration and token renewal. When false, the app can register and renew tokens using just an authentication assertion. See Attestation vs Assertion for more details.

A successful response returns a 201 status code with the created Verifier Application:

Response
{
    "id": "a82bfa46-72a0-4cde-b6cb-2a0de7e2f3c4", 
    "name": "My Android Verifier Application",
    "type": "android",
    "packageName": "com.yourcompany.verifierapp",
    "packageSigningCertificateThumbprints": [
        "1232584B6F6A892D356899FB9576C5F226A179E6199F2B7A1D837B5C234C5A8E"
    ],
    "maxTimeOfflineInSecs": 864000,
    "keyAttestation": {
        "required": true
    }
}
  • id: A unique identifier for the Verifier Application (generated by the tenant). You must use this value when initializing the SDK so that it can correctly identify and authenticate your application.

SDK Tethering does not apply to the React Native Verifier SDK. You only need to create a Verifier Application if you use remote mobile (app-to-app) verification, where the application id is passed to requestMobileCredentials per request — not at initialization. For in-person (proximity) verification with React Native, no Verifier Application or platform configuration is required.

If you use remote mobile (app-to-app) verification, create a Verifier Application for each platform you target by following the iOS and Android tabs above. You then pass the matching application id to requestMobileCredentials at runtime, selecting it based on Platform.OS:

Example
import { Platform } from "react-native";

const verifierApplicationId =
  Platform.OS === "ios"
    ? "YOUR_IOS_VERIFIER_APPLICATION_ID"
    : "YOUR_ANDROID_VERIFIER_APPLICATION_ID";
  • YOUR_IOS_VERIFIER_APPLICATION_ID : The id returned when you created the iOS Verifier Application.
  • YOUR_ANDROID_VERIFIER_APPLICATION_ID : The id returned when you created the Android Verifier Application.

Initialize the SDK with platform configuration

SDK Tethering is required for the native iOS and Android Verifier SDKs, so you must initialize them with a platform configuration once your Verifier Applications are created. This connects your app to the correct MATTR VII tenant and Verifier Application, registers the app instance, and obtains the license the SDK needs to operate. The React Native Verifier SDK is not tethered and can be initialized without any options for in-person verification — see the React Native tab below.

Initialize the SDK with your platform configuration. The initialize method is asynchronous, so call it from an asynchronous context:

Initialization
let platformConfig = PlatformConfiguration(
    tenantHost: URL(string: "https://your-tenant.vii.mattr.global")!,
    applicationId: "1ef1f867-20b4-48ea-aec1-bea7aff4964c"
)
try await MobileCredentialVerifier.shared.initialize(
    platformConfiguration: platformConfig
)
  • tenantHost: The URL of your MATTR VII tenant. This must be the tenant where your iOS Verifier Application is configured.
  • applicationId: The id of your configured iOS Verifier Application.

Initialize the SDK with your platform configuration:

Initialization
val platformConfig = PlatformConfiguration(
    tenantHost = URL("https://your-tenant.vii.mattr.global"),
    applicationId = "1ef1f867-20b4-48ea-aec1-bea7aff4964c"
)
MobileCredentialVerifier.initialize(context, platformConfig)
  • tenantHost: The URL of your MATTR VII tenant where your Android Verifier Application is configured.
  • applicationId: The id of your configured Android Verifier Application.

The React Native Verifier SDK is not tethered, so initialization does not register an app instance or require an applicationId. You can initialize without any options for in-person (proximity) verification:

Initialization
import { initialize } from "@mattrglobal/mobile-credential-verifier-react-native";

const result = await initialize();

if (result.isErr()) {
    console.error("Failed to initialize SDK:", result.error);
}

If you use remote mobile (app-to-app) verification, pass a platformConfiguration with your tenant host. The tenantHost is the only field, and it is required for requestMobileCredentials:

Initialization (remote mobile)
const result = await initialize({
    platformConfiguration: {
        tenantHost: "https://your-tenant.vii.mattr.global",
    },
});

if (result.isErr()) {
    console.error("Failed to initialize SDK:", result.error);
}

The verifier application id is passed per request to requestMobileCredentials, not at initialization. See the remote mobile verification tutorial for details.

Once your Verifier Application configurations are created, your application will be able to use the SDK and interact with the MATTR VII platform (for example, to verify credential presentations).

Managing application instances

Once your Verifier Application is configured and the SDK is initialized, each device that launches your app registers as a new application instance on your tethered MATTR VII tenant. You can view and manage these instances via the MATTR VII API.

Retrieve all registered instances

To view all registered instances for a Verifier Application and track usage:

Request
GET /v2/presentations/applications/{applicationId}/instances
  • applicationId : The id of the Verifier Application you want to inspect.

The response includes a paginated list of all registered instances:

Response
{
  "data": [
    {
      "id": "1ef1f867-20b4-48ea-aec1-bea7aff4964c",
      "appAttestationType": "app_attestation",
      "registeredAt": "2023-10-05T14:48:00.000Z",
      "licenseExpiresAt": "2024-10-05T14:48:00.000Z",
      "lastAttestedAt": "2023-12-01T10:30:00.000Z",
      "externalReferenceId": "external-ref-12345",
      "deviceDetails": {
        "deviceModel": "iPhone 12",
        "deviceMake": "Apple",
        "osVersion": "iOS 14.4"
      },
      "sdkDetails": {
        "sdkVersion": "1.2.3"
      }
    }
  ],
  "nextCursor": "Y3JlYXRlZEF0PTIwMjAtMDgtMjVUMDY6NDY6MDkuNTEwWiZpZD1hNjZmZmVhNS04NDhlLTQzOWQtODBhNC1kZGE1NWY1M2UzNmM"
}

Each instance includes:

  • id : Unique identifier for the registered instance.
  • appAttestationType : The type of attestation used during registration (none, app_attestation, or key_attestation).
  • registeredAt : When the instance was first registered.
  • licenseExpiresAt : When the instance's license expires (the Verifier SDK will automatically handle license renewal).
  • lastAttestedAt : When the instance was last attested.
  • deviceDetails : Information about the device (model, make, OS version).
  • sdkDetails : Information about the SDK version used by the instance.

This is useful for tracking how many devices are actively using your application and monitoring usage quotas.

Delete a specific instance

To remove a specific registered instance:

Request
DELETE /v2/presentations/applications/{applicationId}/instances/{instanceId}
  • applicationId : The id of the Verifier Application.
  • instanceId : The id of the specific instance to delete.

Once deleted, the instance can no longer interact with the platform or receive tokens, and any existing tokens are revoked.

Deleting instances is primarily useful during testing when you have a limited number of devices and need to re-register a fresh instance (for example, to test the initial registration flow again). In production, there is nothing preventing the application from requesting another token on the next launch, which would create a new instance — so deleting instances is not an effective way to block a device.

Attestation vs Assertion fall-back

When configuring a Verifier Application, you control whether your MATTR VII tenant requires attestation (hardware-backed proof of app integrity) or also accepts a lighter-weight assertion (a cryptographic signature proving key possession) during instance registration and token renewal.

Each platform has an attestation configuration with a required boolean:

  • When required is true, the app instance must provide a valid attestation during registration and token renewal.
  • When required is false, your tenant also accepts an assertion when an attestation is not available.

The SDK handles this automatically. It always attempts to provide an attestation, and falls back to an assertion if it cannot generate one (for example, when the platform attestation service is temporarily unavailable). Your tenant then accepts or rejects the request based on the required setting. Your application does not need to manage attestation or assertion details directly.

When to use each setting

ScenarioRecommended setting
Production apps in distributionrequired: true — Provides the strongest integrity guarantees by verifying the app and device through OS-level attestation.
Development and testingrequired: false — Useful when running on simulators or devices where attestation services are unavailable.
Broad device compatibilityrequired: false — Some older devices may not support hardware attestation. The assertion fall-back ensures these devices can still register.

Setting attestation to required: false reduces the security guarantees of the tethering process. Only use this setting when you have a specific need, such as supporting older devices or during development.

How would you rate this page?

Last updated on

On this page