Credential Holding
Add credential holding to your product with the MATTR Pi Holder SDKs. Understand the holder lifecycle (claim, hold, present), set up your app, then follow the guide for each part.
Credential holding lets your users receive, store, and present verifiable credentials (such as mobile driver's licenses, employee badges, or proof-of-age tokens) from a mobile app they trust. The MATTR Pi Holder SDKs give you native iOS, Android, and React Native libraries to build this into your own app. This section explains the holder lifecycle, then links to the detailed guide for each part.
How credential holding works
A holder app does three things across the life of a credential:
- Claim: receive a credential from an issuer and store it securely on the device.
- Hold: keep the credential safe, under the user's control, ready to use.
- Present: share the credential with a verifier, in person or remotely, with the user's consent.
A claimed credential is only useful once it can be presented, so claiming and presenting are two ends of the same journey. The pages below follow that order.
The holding lifecycle at a glance
The SDKs cover the whole lifecycle. Set up your holder app, then work with credentials.
Get started
Set up your holder app
Check system requirements, then install and initialize the Holder SDK.
Run the quickstart
Run a sample holder app end-to-end in 15-20 minutes.
Work with credentials
Claim a credential
Receive and store a credential from an issuer via OID4VCI.
Present a credential
Share a stored credential with a verifier, in person or remotely.
Know what you need? Jump straight to
Claiming
Offer handling, journey patterns, tutorial, and guides.
Presenting
In-person (proximity) and remote presentation, including the DC API.
Wallet Attestation
Prove your wallet is trusted so issuers that require it will release credentials, plus PKI, certificates, and Android app signing.
Operate
SDK Backend, logging, activity logs, and migration guides.
How the pieces fit together
The typical integration involves your mobile app, the MATTR Pi Holder SDK, and MATTR VII as the backend platform.
| Component | Role |
|---|---|
| Your mobile app | User interface, business logic, navigation |
| MATTR Pi Holder SDK | Credential operations (claim, store, present) |
| MATTR VII | Issuer and verifier backend (offers, sessions, trust) |
| Device secure storage | Credential and key storage, managed by the SDK |
Present a credential
A stored credential becomes useful when the holder presents it to a verifier. MATTR Holder SDKs support two presentation modes, and most apps eventually support both. Which you build first depends on where your verifiers are.
Present in person (proximity)
Choose in-person presentation when the holder and verifier are physically together, such as showing a mobile driver's license to an official or a self-service kiosk.
The holder's device and the verifier's device establish a direct connection over proximity technologies such as Bluetooth Low Energy, following ISO/IEC 18013-5. This works offline, with no network required at presentation time.
See the in-person presentation overview to build this flow.
Present remotely
Choose remote presentation when the holder and verifier are not in the same place, such as an online sign-up or a remote identity check.
The verifier sends a request to the holder's app over the web, following ISO/IEC 18013-7 and OID4VP. Requests can arrive by redirect, QR code, or the browser-integrated Digital Credentials API.
See the remote presentation overview to build this flow.
Which should you build?
- Build in person first for physical, face-to-face use cases such as mDL checks at a venue.
- Build remotely first for online use cases such as web onboarding or cross-device verification.
- Many apps support both. The SDK handles each mode independently, so you can add the second later.
Trusted verifiers
Whenever a verifier requests a credential, your holder app should confirm who is asking before it releases any data. A holder is sharing potentially sensitive personal information, so establishing that the verifier is trusted, and surfacing that trust to the user, is an essential part of a safe presentation flow. The SDK validates the verifier's identity against a list of trusted verifier certificates and reports the outcome, so your app can decline or warn on requests from verifiers it cannot authenticate.
This applies to both presentation modes, and each has a dedicated guide:
Trusted verifiers is the plain-language name for this idea, and it is how these guides are labelled in the navigation. The underlying mechanism is Verifier Authentication, the term used throughout the SDK and the rest of these docs. For in-person presentation, ISO/IEC 18013-5 calls the same mechanism Reader Authentication. All three names refer to the one concept: confirming that a verifier is who it claims to be before sharing credential data.
Finding your way around
Each part of the holder lifecycle has a set of pages, and the type of page tells you what to expect:
- Quickstart: For assessing the capability. It gets a solution working end-to-end as fast as possible, without building everything or covering every option.
- Tutorial: For learning how to do it while doing it. It walks you through the process step by step and adds context along the way.
- Guide: For users who already know the outcome they want. It gives a direct path to a specific, usually isolated, task.
Where to go next
- Already building? See Wallet Attestation for how issuers trust your app, including PKI and certificates, and Holder SDK Operation for backend, logging, and activity logs.
- Have a question? See the Holding FAQ.
Other options
Building your own holder app with the SDKs is one way to hold credentials. If you would rather not build and maintain a wallet, MATTR GO Hold is a ready-made wallet app you can deploy as-is or white-label, with no mobile development. For a full comparison of the two paths, see SDK or ready-made wallet?.
How would you rate this page?
Last updated on