Learn how to setup a Digital Trust Service (DTS)
Introduction
The purpose of a Digital Trust Service (DTS) is to enable different participants in a digital ecosystem to rely on a single trusted framework.
This tutorial will guide you through using the Portal to set up a DTS and publish a policy that defines trusted participants and credential types.
Prerequisites
- Make sure you understand the concepts of a DTS and how it relates to Ecosystem operations.
- You need access to an existing MATTR VII tenant with either the
DTS ProviderorAdminrole. Refer to the Getting started with the Portal tutorial to learn how to create a tenant and assign roles.
Tutorial overview
Setting up a DTS comprises the following steps:
- Create an Ecosystem: This is the container for all the participants and policies that define the trust framework.
- Create a participant: These are the entities that will be part of the trust framework, such as issuers and verifiers.
- Configure valid Credential types: These are the types of credentials that will be issued and verified within the trust framework.
- Configure roles and permissions: This step involves defining what each participant can do, such as issuing or verifying credentials, and whether they are constrained to specific credential types.
- Publish a policy: This is the final step where you publish the policy that defines the trust framework and its participants.
Tutorial steps
Create an Ecosystem
The Ecosystem acts as the overarching entity that holds all the other components together. Each Ecosystem defines its own:
- Participants: Issuers and/or verifiers that are valid in the ecosystem.
- Credential Types: Credential types that are valid in the ecosystem.
- Policies: Define what participants are allowed to issue and/or verify different types of credentials within the ecosystem.
Perform the following steps to create an Ecosystem:
- Log in to the Portal.
- Navigate to the Ecosystem page under the Digital Trust Service section.
- Enter a name for your Ecosystem, such as "My Digital Trust Service".
- Select the Create button.
Create a participant
Participants are entities within an ecosystem that can be issuers and/or verifiers. When issuers/verifiers are onboarded as valid participants in the ecosystem, they are assigned with unique identifiers that identify them when they issue and/or verify credentials. For example, each issuer can be associated with an IACA certificate that they use to sign and issue credentials.
Perform the following steps to create a participant:
- Select the Participants tab.
- Select the Create new button.
The Create ecosystem participant form appears, starting from Step 1 (Details). - Insert a meaningful Name for the participant.
- Use the Country dropdown list to select the Participant’s country (optional). Note that when selected, this value must match the Country value in the IACA certificate associated with this participant.
- If you select a country, a State or Province dropdown list is displayed. You can use it to select the Participant’s state or province (optional). Note that when selected, this value must match the StateOrProvinceName value in the IACA certificate associated with this participant.
- Insert the participant’s Address (optional).
- Insert the participant’s Phone number (optional).
- Use the Status radio button to set the participant as Active.
- Click the Next button.
You are directed to Step 2 (Certificates). - Select the Add new button.
- Upload the PEM file you want to use as this participant’s identifier for issuing mDocs (this must be a
valid IACA certificate and match any values set for Country and State or Province above).
You should now see the certificate summary and details. - Scroll down and use the Certificate status dropdown list to set the certificate as Active.
- Click the Add button.
- Click Create.
Publish a policy
Ecosystem policies combine participants and credential types to determine permissions within the ecosystem. For example, participant X can act as an issuer and issue valid credentials of type X, Y and Z.
- Issued credentials are only considered valid when they reference a unique identifier of an issuer that is a participant in the ecosystem and is allowed to issue that credential type.
- Verification requests are only considered valid when they reference a unique identifier of a verifier that is a participant in the ecosystem and is allowed to verify that credential type.
These roles are then bundled together into a policy and published for relying parties to consume.
The last step in this tutorial is to publish a policy that will includes the participant and credential type you created earlier, as well as the constraints you applied to the participant's role.
Currently the Portal only enables publishing a policy as a Verified Issuer Certificate Authority List (VICAL).
Perform the following steps to publish your DTS policy as a VICAL:
Create a DTS root CA
Each VICAL must be linked to a trusted root CA via a chain of trust. Perform the following steps to create a DTS root CA:
- Navigate to the Certificates page under the Platform Management section.
- Use the Type dropdown list to select DTS CA.
- Use the Management method radio button to select MATTR managed.
- Enter a meaningful name in the Organisation field to identify the organization that will be signing the policy.
- Use the Country dropdown list to select the country where the organization is located.
- Select the Create button.
- Use the Status radio button to select Active.
- Select the Update button.
Your new DTS root CA is now ready and can be used to establish trust in your VICAL.
Generate and Publish a VICAL
- Return to the Ecosystem page under the Digital Trust Service section.
- Select the Publish tab.
- Enter a meaningful Provider name to identify the provider of the VICAL.
- Use the Generation method dropdown list to select Auto generate.
- Select the Create button.
- Select the Generate & Publish button.
The VICAL is now generated and published, and a modal is displayed where you can:- Use the Download button to download the VICAL policy file.
- Copy the link to the public endpoint where relying parties can access the policy.
How would you rate this page?