Remote verification implementation guidelines

Overview

MATTR provides verification capabilities through both the MATTR Pi Verifier Web SDK and Verifier Mobile SDK, enabling relying parties to seamlessly request and verify verifiable credentials within their own applications.

This short guide explains the recommended implementation pattern for integrating the Verifier SDK, including the typical flow and its benefits. It also highlights a practice to avoid, so you can design a solution that is both technically robust and delivers a smooth, trusted experience for users.

Recommended implementation pattern

The recommended design principle is to integrate the Verifier Mobile/Web SDK directly into the relying party’s web or mobile applications. This ensures that verification requests are trusted by wallets, and the user experience remains consistent and secure.

Typical flow

1. User interacts with your relying party web or mobile application.
2. Application requests a credential presentation via the Verifier SDK.
3. Wallet validates the origin of the request against its trusted relying party list (e.g., web domain or mobile package ID).
4. Credential is presented back to your application.
5. Verifier SDK verifies the credential.
6. Interaction continues seamlessly.

What this achieves

• Trust and compliance: OEM wallets (Apple, Google, Samsung) enforce strict origin checks, ensuring only registered relying parties can request credentials from these wallet applications. Third-party wallets (such as government-issued wallets) are also likely to adopt similar controls for both security and commercial reasons.
• Smooth user experience: Users never leave your application, keeping the interaction intuitive and consistent.
• Future-proof integration: Embedding the SDK avoids wallet validation failures and ensures your solution remains interoperable as wallet ecosystems evolve.

Best practices

Avoid mediated verification windows

An alternative pattern sometimes considered is to redirect the user to a mediated or intermediate window where the SDK is embedded, perform the verification there, and then redirect the user back to the relying party application. This approach should be avoided for two reasons:

1. Technical incompatibility: OEM and third-party wallets will reject credential requests from applications that are not directly registered as relying parties, making mediated flows unreliable.
2. Poor user experience: Redirecting users between apps or browsers fragments the journey, creates confusion, and increases the risk of dropouts.