Integration points
Map what a trust network operator connects to MATTR VII and what participants connect to consume published trust, from participant onboarding through to VICAL and RICAL consumption.
A Digital Trust Service has two kinds of integrators, and they connect to different things. An operator publishes trust. A participant consumes it. This page maps the connections for each, so you can scope your work from whichever side you sit on.
See DTS options for the available mechanisms for distributing trust. This page covers what you connect rather than which mechanism to choose.
Two integration roles
| Role | What you are doing | Where your integration work sits |
|---|---|---|
| Trust network operator | Onboarding participants and publishing which of them are recognized | Your accreditation systems, and MATTR VII ecosystem configuration |
| Participant | Loading published trust into an application or service | Your holder app, verifier app, or verification backend |
Most organizations are one or the other. A few are both, for example an operator that also issues credentials into its own network.
The integration boundary
MATTR VII does not decide who is trustworthy. That decision belongs to your accreditation process, and it usually happens outside any software MATTR provides.
MATTR VII does not:
- Run your accreditation or assessment process.
- Decide which participants qualify.
- Host the applications that consume the published trust.
MATTR VII does:
- Store participants, their contacts, their evidence, and their certificates.
- Hold the ecosystem policy that says which participants may issue or verify which credential types.
- Sign and publish trust lists, including VICALs for issuer trust and RICALs for reader trust.
- Maintain the DTS certificate hierarchy those lists are signed against.
Operating a trust network
The operator side is a sequence of configuration steps, each with its own API surface.
| Integration point | Who owns each side | MATTR surface | Guide |
|---|---|---|---|
| Ecosystem and credential types | You define the ecosystem and the credential types it recognizes | Ecosystems and Ecosystem Configuration APIs | DTS overview |
| Participant onboarding | Your accreditation process decides, MATTR VII records the outcome | Participants API and its evidence, contacts, and certificate resources | Create a participant |
| Policy publication | You define the policy, MATTR VII evaluates and publishes it | Policy, Issuer Policy, and Verifier Policy APIs | Trusted lists, Retrieve the latest policy |
| DTS PKI and signers | MATTR VII manages the hierarchy, you govern its use | DTS Root CA, VICAL Signers, and RICAL Signers APIs | DTS PKI, DTS certificates |
| VICAL publication | You configure it, MATTR VII signs and hosts it | VICAL and VICAL Configuration APIs | VICAL guide |
| RICAL publication | You configure it, MATTR VII signs and hosts it | RICAL and RICAL Configuration APIs | RICAL guide |
Participant onboarding is covered by the API reference rather than a narrative guide. Start from Create a participant, then work through the related resources for evidence, contacts, and issuer and verifier certificates.
The connection worth planning carefully is the first one in that list. Your accreditation process almost certainly already exists, in a case management system, a spreadsheet, or a governance workflow. The integration question is how an accreditation decision becomes a participant record and a policy entry in MATTR VII, and whether that transfer is manual, scripted, or driven by your own systems through the API.
Consuming published trust
Participants integrate on the other side of the same lists.
As a Holder app. Your app loads Reader Root Certificates so it can authenticate verifiers before releasing data, and it can load issuer trust so it can tell the holder whether a credential comes from a recognized issuer. See RICAL consumption and Trusted issuers.
As a verifier. You load issuer certificate authorities from a VICAL, rather than maintaining a list of issuers yourself. This is the single biggest reason to join an ecosystem, because it removes the need for a direct relationship with every issuer. See VICAL consumption, Remote trusted issuers, and In-person trusted issuers.
As any participant. Ecosystem policy is available through the MATTR VII API, so you can check what a given participant is permitted to issue or verify. See DTS options.
Two operational facts shape every consumer integration, and neither is a MATTR setting:
- You own the refresh cadence and caching. Trust lists change when the operator publishes a new version. How often you fetch, and how long you cache, is your decision and your risk.
- Offline consumers must pre-load. An in-person verifier or a Holder app presenting offline has no way to fetch trust material at the moment it needs it. Design the refresh to happen while the device still has connectivity.
Related integration points
- Issuance integration points for how an issuer gets the certificates that a VICAL then distributes.
- Verification integration points for the verifier side of trust consumption.
- Holding integration points for the Holder app side.
- Platform management integration points for tenant provisioning and access control.
Next steps
- Understand the model in the DTS overview.
- Compare distribution mechanisms in DTS options.
- Publish issuer trust with the VICAL guide, or reader trust with the RICAL guide.
How would you rate this page?
Last updated on