Ecosystem operations

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.

Create Ecosystem Participants

Once an ecosystem is in place, the next step is to create valid participants, that can be issuers and/or verifiers.

Participants are entities within an ecosystem that can be issuers and/or verifiers (one participant can assume both roles). Participants might be government agencies, insurance companies, banks, universities and so on.

When issuer/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. This enables the holder’s digital wallet to provide visual indication of this status in interactions with a participant. Holders can now find it easier to establish trust in the interaction, as they know the issuer/verifier was assessed and found trustworthy by the ecosystem operator as part of their onboarding process.

Participants can also be constrained to only issue and/or verify specific credential types. When participants are not constrained, they are able to issue and/or verify any credential type in the ecosystem.

This does not mean that other parties cannot issue and verify credentials in the ecosystem. If the ecosystem operator chooses to enable this, holders can interact with issuers/verifiers that were not onboarded as participants in the ecosystem. The main difference is a decreased level of trust holders can have in these interactions, as they are unknown to the ecosystem operator.

Note that participants are only considered valid after they are added to an issuer and/or verifier policy.

Identifiers

Participants are configured with unique identifiers that are used to identify them when they issue and/or verify credentials, so that they can be trusted in digital interactions:

• 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 according to the Ecosystem policy.
• 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.

For JSON and CWT credentials, the identifier would be the issuer’s DID, while for mDocs it would be the IACA used by the issuer to sign mDocs.

Each participant must have at least one identifier that is linked to a credential format, and multiple identifiers linked to different credential formats.

Constraints

Participants can be constrained to only issue and/or verify specific credential types. When participants are not constrained, they are able to issue and/or verify any credential type in the ecosystem.

Configure valid Credential types

Alongside participants, an integral part of setting up an ecosystem is configuring credential types which are considered valid in the ecosystem.

Credential types define what credentials are valid in the ecosystem. Similar to participants, each configured credential type is configured with a unique identifier which makes it easier for holders to trust interactions involving this specific credential type.

Again, this does not mean that other credentials cannot be issued or verified in the ecosystem. The ecosystem operator can enable issuing and verifying other types of credentials, but these will not carry with them the same level of trust as credential types that were configured as valid.

When required, ecosystem operators can delete a configured credential type so that it is no longer considered valid in the ecosystem.

Create Policies

Combining participants and credential types, Ecosystem policies configure roles and permissions that apply within the ecosystem. For example, participant X can act as an issuer and issue valid credentials of type X, Y and Z.

Ecosystem policies are publicly available and can be accessed unauthenticated by design. This enables different parties to check whether an issuer is allowed to issue a certain credential type in the ecosystem, or whether a verifier is allowed to verify a certain credential type in the ecosystem.

It is up to the policy consumer to apply their own business logic based on the information found in the policy. For example, some parties might prevent a holder from retrieving a credential from an issuer that is not valid in the ecosystem, while others might only warn the holder but still enable claiming the credential from this unknown issuer.

Ecosystems have separate policies for issuers and verifiers:

• Issuers policy: Includes a list of issuers and what credential types they can issue. Note that if an issuer is not constrained, a policy will not limit what credential types they can issue.
• Verifiers policy: Includes a list of verifies and what credential types they can verify. Note that if a verifier is not constrained, a policy will not limit what credential types they can verify. Note that participants are only considered valid after they are added to an issuer and/or verifier policy.

When required, ecosystem operators can remove a participant from a policy so that it is no longer trusted to issue and/or verify credentials in the ecosystem.

Retrieving a policy

Once a policy is created, various participants can retrieve and use it to apply their own business logic in different digital interactions scenarios. For example, retrieving parties can check whether:

• An issuer is trusted to issue a certain credential type in the ecosystem.
• A verifier is trusted to verify a certain credential type in the ecosystem.

To enable this, policies are publicly available and can be accessed in an unauthenticated manner.

Once a policy is retrieved, it is up to the retrieving party to apply their own business logic based on the information found in the policy. For example, some parties might prevent a holder from retrieving a credential from an issuer that is not valid in the ecosystem, while others might only warn the holder but still enable claiming the credential from this unknown issuer.