Integration points

Embedding credential holding in a mobile app is mostly a question of boundaries. Some things belong to your app, some to the MATTR Pi Holder SDK, some to the operating system, and some to your MATTR VII tenant. This page maps those boundaries and names the objects that join them.

The Holding overview describes the four layers involved. This page goes one level down, to the specific connections you have to create and maintain.

The integration boundaryCopy Anchor Link

Four things join the layers together.

• The Holder Application record on your MATTR VII tenant. You create one per platform target, identified by the bundle identifier on iOS or the package signing certificate thumbprint on Android. A React Native app targets both platforms, so it needs two.
• The platform configuration you pass at SDK initialization. This enables the SDK Backend. It is optional today, and MATTR expects to make it required in an upcoming release, so treat it as part of the integration rather than something to add later.
• The URI scheme or deep link registered in your app manifest. Configured in your app, not the SDK. It is how credential offers and presentation requests reach your app.
• Device secure storage, biometrics, and passcode. The operating system owns these. The SDK uses them, and you set the policy.

Integration points at a glanceCopy Anchor Link

Claiming a credentialCopy Anchor Link

Claiming is where your app touches the most external systems, and where the boundary is easiest to get wrong.

• The offer arrives from outside your app. It comes as a deep link or a scanned QR code, so the handling belongs to your app manifest and the operating system before the SDK sees it. See Claiming URI scheme handling.
• Authentication may not be yours. In the Authorization Code flow, your app opens a browser session against an identity provider the issuer controls. You host the session, but you do not control what happens inside it. In the Pre-authorized Code flow that step does not exist. See the claiming overview and the claiming journey patterns.
• The issuer may require your app to prove itself. If it does, wallet attestation becomes a hard dependency, and it needs the SDK Backend configured. See Wallet attestation.
• You decide which issuers to accept. The SDK enforces the list you give it. See Trusted issuers.
• Storage is handled for you. The SDK stores credentials and keys in device secure storage. You set the authentication policy over them. See Device key authentication.

Presenting in personCopy Anchor Link

In-person presentations run offline.

• Permissions belong to your app. Bluetooth and NFC permissions go in your app manifest, with the usage strings your app store listing requires. See NFC engagement.
• Device engagement is a user interface problem. Displaying a QR code or presenting for an NFC tap is your screen, driven by the SDK. See In-person presentation.
• Trust material has to be pre-loaded. Because there is no network at presentation time, every trusted verifier certificate must already be on the device. Decide the refresh cadence during integration, not after launch. See Verifier authentication.
• Consent is your screen. The SDK reports what is being requested. You decide what the holder sees and how they approve it.

Presenting remotelyCopy Anchor Link

Which remote journeys you support is a user experience decision first. Each journey then has its own entry paths into your app, and which ones you support is an integration decision.

• Same-device. The holder reaches the verifier on the same device that holds their credentials. The request arrives through a redirect or deep link handled by your registered URI scheme, or through the Digital Credentials API.
• Cross-device. The holder reaches the verifier on another device, such as a desktop browser, and scans a QR code with their phone. The scanned request arrives through your registered URI scheme, or through the Digital Credentials API.

For URI scheme entry, see Remote URI scheme handling. For the Digital Credentials API, the SDK registers your app as a credential provider, and registers the credentials it holds, with the operating system. The operating system then mediates the request. See DC API. For how each journey looks to the holder, see the remote presentation journey patterns.

Verifier authentication applies here too, and the trust source can be a RICAL published by an ecosystem operator. See Verifier authentication and RICAL consumption.

If you use MATTR GO Hold insteadCopy Anchor Link

MATTR GO Hold moves the boundary. MATTR owns the application and its SDK integration, and you own branding, configuration, the MATTR VII tenant behind it, and the app store publishing model. There is no mobile development, so the integration points reduce to tenant configuration, trust configuration, and distribution.

For a comparison of the two paths, see SDK or ready-made wallet.

Related integration pointsCopy Anchor Link

• Issuance integration points for the issuer side of claiming.
• Verification integration points for the verifier side of presentation.
• Digital Trust Service integration points for where trusted issuer and trusted verifier lists come from.
• Platform management integration points for tenant provisioning, access control, and observability.

Next stepsCopy Anchor Link

• Set up your app from the Holder SDK overview.
• Run the Holder SDK quickstart.
• Compare MATTR VII, MATTR Pi, and MATTR GO in Platforms.