Frequently asked questions
Answers to common questions about Digital Trust Services with MATTR VII. For the concepts behind these answers, see the Digital Trust Service overview.
Frequently asked questions
What is a Digital Trust Service?
A Digital Trust Service (DTS) is the component of a trust network that publishes who and what the network trusts. Instead of every participant establishing a direct relationship with every other participant, each participant trusts the lists the network operator publishes through the DTS. It is the network operator's responsibility to establish trust in individual entities, and the DTS reflects that trust to everyone else.
Why use a DTS instead of direct trust relationships?
Direct trust means every participant exchanges and manages keys with every other participant. That works in a small network, but the number of relationships grows with every new participant, and each one has to be maintained as certificates rotate. A DTS replaces that mesh with proxy trust, where participants establish trust once with the DTS and rely on it for everything else. See direct and proxy trust.
What do the trusted lists actually contain?
A DTS publishes three separate categories of trust, each answering a different question:
- Trusted issuer lists: who is authorized to issue a given credential type.
- Trusted reader lists: who is authorized to request (read) a given credential type.
- Trusted wallets and technologies: which certified applications may participate in the network.
Entries identify participants by a certificate or identifier, such as an IACA or a DID, along with the credential types they are authorized to use. They do not contain personal information about credential holders. See Trusted Lists.
How do I choose between a VICAL, a RICAL, and wallet attestation?
Start from the category of trust you need to publish or consume:
- A signed list of trusted issuer certificate authorities: use a VICAL.
- A list of trusted readers (verifiers): use a RICAL.
- Certified wallets and technologies: use wallet attestation alongside the certification criteria in your trust framework.
These options are not mutually exclusive. See DTS options for the full comparison.
What is the difference between a VICAL and a RICAL?
They are counterparts that serve opposite directions of the same interaction:
- A VICAL (Verified Issuer Certificate Authority List, defined in ISO/IEC 18013-5 Annex C) collects IACAs from issuing authorities, so relying parties can verify mDocs from many issuers against a single signed list.
- A RICAL (Reader Identity Certificate Authority List, defined in ISO/IEC 18013-5 Annex F) collects Reader Root Certificates from relying parties, so holder applications can authenticate the verifier that is requesting data.
Put simply, a VICAL tells verifiers which issuers to trust, and a RICAL tells wallets which verifiers to trust.
Do I need to operate a DTS to issue or verify credentials?
No. Issuance and verification work without one. A DTS becomes valuable when the number of participants makes direct trust impractical, or when your ecosystem needs a single authoritative answer to who may issue and who may verify. Operating a DTS is a network operator role, not an issuer or verifier role. See MATTR capabilities.
What certificates does a DTS need?
Every trusted list is signed by a signer certificate that chains back to a DTS root CA: a VICAL Signer Certificate (VSC) for a VICAL, or a RICAL Signer Certificate (RSC) for a RICAL. That chain is what lets a consumer verify the authenticity and integrity of the list it downloaded. See DTS certificates for the full requirements, and PKI and key management for how this fits into MATTR's wider PKI.
Should I use the 2-tier or the 3-tier certificate model?
The 2-tier model is the default. A DTS root CA signs the signer certificate directly, which means fewer certificates to issue, manage, and renew. The 3-tier model inserts a DTS intermediate CA between the two, which lets you keep the root private key offline and revoke or replace the intermediate without rotating the root.
Choose the 3-tier model if your PKI policies require a layered hierarchy, or if you need to delegate signing to separate intermediate authorities. Note that the 3-tier model requires unmanaged (external) certificates for both the root and the intermediate CA, so you cannot use it if you want MATTR VII to manage your DTS root CA. See choosing a model.
How do participants consume trust information from a DTS?
Through whichever option the network operator publishes. VICALs and RICALs are published as signed lists that participants download and cache, then check locally when they need to make a trust decision. Consumption is asynchronous, so it happens independently of any individual presentation.
What is a trust framework, and who maintains it?
The trust framework is the legal and policy foundation the network runs on. It defines the policies that govern how participants may operate, the recognized standards that keep participants interoperable, and the schemes and vocabularies that fix the content and structure of supported credentials. The network operator maintains it and acts as the accreditation body, assessing compliance, onboarding and offboarding participants, and auditing continued adherence. The DTS is how that framework becomes machine-readable. See trust framework.
What are trust marks?
Trust marks are the user-facing side of trust information. Once an application has consumed trust information from a DTS, it can show the user a badge, seal, or indicator confirming that the party they are interacting with is recognized by the network. For example, a wallet can display a trust indicator when a verifier appears on the network's reader list, and warn the user when it does not. See trust marks.
Does a DTS see individual credential presentations?
No. A DTS publishes trust information that participants consume independently. It is not on the transaction path between a holder and a verifier, so it does not see who presented what to whom. For the full privacy posture, including what MATTR's DTS capability deliberately does not do, see Privacy in digital trust services.
How would you rate this page?
Last updated on