light-mode-image
Learn
MobileSDKs

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 required from the following SDK versions:

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

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 and team ID (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

While a Verifier Application can be created in the MATTR Portal, the settings that govern SDK Tethering are only available via the MATTR VII API. Any creation or update of a Verifier Application that supports SDK Tethering must therefore be performed using the API. Portal support will be added in the near future.

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",
    "appAttest": {
        "required": false,
        "environment": "development"
    }
}
  • 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 (must match the Team ID used to sign your app).
  • 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",
    "appAttest": {
        "required": false,
        "environment": "development"
    }
}
  • 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"
    ],
    "keyAttestation": {
        "required": false
    },
    "openid4vpConfiguration": {
        "redirectUri": "com.yourcompany.verifierapp://oid4vp-callback"
    }
}
  • 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.
  • 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.
  • openid4vpConfiguration.redirectUri: Required by the create-application endpoint, which needs at least one of openid4vpConfiguration or dcApiConfiguration. In-person proximity verification does not use this redirect, so any valid custom-scheme URI is accepted here.

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"
    ],
    "keyAttestation": {
        "required": false
    }
}
  • 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 is currently not available in the React Native Verifier SDK.

Initialize the SDK with platform configuration

When you initialize the SDK, you must provide a PlatformConfiguration object with your tenant host and the id of the Verifier Application you created. This allows the SDK to register the app instance with your tenant and obtain a license to operate.

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.

SDK Tethering is currently not available in the React Native Verifier SDK.

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