Privacy in digital trust services

A Digital Trust Service (DTS) lets the operator of a trust network publish information that participants need to evaluate trust: which issuers are accredited, which verifiers can request which credentials, and what credential types are recognized in the ecosystem.

This page describes the privacy properties of a DTS, why it does not introduce a central point of surveillance, and how MATTR's DTS capability is designed to preserve the decentralized model.

For the broader picture, see Privacy in MATTR's architecture.

A DTS is a publication mechanism, not a transaction broker

The most important privacy property of a DTS is the role it plays in the architecture. A DTS:

• Publishes trust information so that issuers, holders, and verifiers can evaluate trust locally.
• Does not sit on the transaction path between holder and verifier.
• Does not see individual presentations.

This is what makes proxy trust (where every participant trusts the DTS) compatible with the decentralized model. The DTS replaces the manual work of negotiating bilateral trust between every pair of participants, without becoming an intermediary in every verification interaction.

Compare this to a federated identity provider, where the intermediary has to see every authentication request in order to issue an assertion. A DTS does not have that property. Once a verifier has fetched the trust list, it can verify credentials without ever talking to the DTS again.

What is in a trust list

Trust lists published by a DTS contain entries that identify participants and the role they play in the ecosystem. Typical contents include:

• Trusted issuer entries (often anchored to an IACA).
• Trusted verifier entries, where the ecosystem requires accredited verifiers.
• Recognized credential types and their associated formats.
• Cryptographic signatures by the DTS operator over the published lists, so that consumers can verify the lists' integrity.

Trust lists do not contain personal information about credential holders. They are about the participants in the trust network, not about the people whose data flows through the network.

For ecosystems that consume trust information as a VICAL (defined in ISO/IEC 18013-5), the VICAL is similarly a list of trusted issuer certificate authorities, signed by the VICAL operator. It does not contain holder data.

How participants consume trust information

MATTR's DTS capability supports several consumption patterns. In all of them, the consumer fetches trust information independently of any specific verification:

• MATTR VII APIs: The trust network operator publishes ecosystem policies that define participants and the credential types they can issue or verify. Issuers, holders, and verifiers can fetch these policies via API.
• MATTR Pi and MATTR GO SDK integrations: Holder and verifier SDKs can consume ecosystem information and apply it to the local presentation flow.
• VICAL: For ecosystems that follow the ISO/IEC 18013-5 model, the operator can publish a signed VICAL that relying parties consume on a schedule.

In every pattern, the fetch is asynchronous and is not associated with a specific verification. The DTS sees that some participant fetched a list. It does not see what verification activity, if any, that fetch was related to.

What MATTR's DTS capability does NOT do

The MATTR VII DTS capability is designed as a publication mechanism. It explicitly does not:

• Receive verification events from participants.
• Maintain a per-holder ledger of credentials or presentations.
• Sit in the transaction path between holder and verifier at presentation time.

If a customer operating a DTS chooses to layer additional ecosystem-level analytics or reporting on top, that is a separate system that the operator is responsible for designing and disclosing. The core DTS capability does not introduce a central surveillance point.

Trust frameworks and the rules around DTS operation

A DTS does not operate in a vacuum. It is the technical expression of a trust framework: the governance rules that define how participants are accredited, what claims credentials may carry, and what obligations sit on issuers, holders, and verifiers.

Many trust frameworks explicitly prohibit issuers, wallets, and trust framework providers from tracking or correlating verification activity. Where this applies, the DTS operator's job is to design the service so that compliance is enforced architecturally rather than depending on each participant's good behavior. MATTR's DTS capability supports this by keeping the DTS out of the verification path.

See Decentralized trust model for a fuller treatment of how governance instruments need to change as the architecture changes.

Practical guidance for DTS operators

If you are operating a DTS with MATTR VII, the following principles help preserve the architecture's privacy properties:

• Publish trust information in a form that is consumable without identifying the consumer. Authenticated APIs are fine, but the authentication should identify the consuming organization, not individual transactions.
• Sign published lists. Consumers should be able to verify the integrity of the trust information independently of the transport.
• Define a clear policy for what the DTS may and may not log about consumption. Most operators benefit from aggregate consumption metrics; per-participant transactional logs are rarely needed and easily abused.
• Make trust framework obligations explicit. Issuers, holders, and verifiers should know what they are signing up to when they join the ecosystem.
• Choose the regional MATTR deployment that matches the data residency expectations of the ecosystem you are operating.

Frequently asked questions

Does a Digital Trust Service see individual credential presentations?

No. A DTS publishes trust information (lists of trusted issuers, verifiers, and credential types) that participants consume independently. It is not on the transaction path between holder and verifier, and it does not see who is presenting what to whom.

What does a trust list contain?

A trust list contains entries that identify participants in the trust network (typically by IACA, DID, or signer certificate) and the credential types they are authorized to issue or verify. It does not contain personal information about credential holders.

Why use a DTS instead of direct trust relationships?

Direct trust relationships are workable in small ecosystems but do not scale. A DTS lets every participant rely on a single trust anchor maintained by the network operator, rather than negotiating bilateral trust with every other participant. This keeps the architecture decentralized without requiring every party to vet every other party.

Can a DTS be used to log verifications across an ecosystem?

No. MATTR's DTS capability is designed as a publication mechanism and does not receive verification events from participants. Ecosystem-level verification logging would require a separate reporting or analytics system layered outside the DTS, which the customer would be responsible for designing and disclosing. Doing so is also typically prohibited by the trust framework rules that govern the DTS, as many trust frameworks explicitly prevent the DTS from collecting verification activity.

How do verifiers consume trust information from a MATTR DTS?

Trust information can be consumed via the MATTR VII Ecosystem APIs, via MATTR Pi and MATTR GO SDK integrations, or as a VICAL (a signed Verified Issuer Certificate Authority List defined in ISO/IEC 18013-5). The consumption is asynchronous and does not identify the verification activity that triggered it.

Related reading

• Privacy in MATTR's architecture
• Decentralized trust model
• Digital Trust Service overview
• VICAL
• Chain of trust