> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md).

# 4. Ecosystem & Trust

## 4.1 Roles

| Role                          | What they do                                                                                         | Examples in education                                                                                                                                           |
| ----------------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Issuer**                    | Creates, signs and manages credentials; keeps the record that allows re-issuance and status changes. | Schools, universities, examination boards, ministries, training providers, awarding bodies.                                                                     |
| **Holder**                    | Receives, keeps and shares credentials                                                               | Learners and graduates; parents or guardians for minors; an institution acting on a learner's behalf in LVC-2.                                                  |
| **Verifier**                  | Checks that a credential is genuine, was issued by an authorised issuer, and is still valid.         | Employers, admitting institutions, licensing bodies, immigration and recognition authorities, scholarship funds.                                                |
| **Trust registry**            | Lists which issuers are genuine and which credential types each is authorised to issue               | Accreditation agencies, qualifications authorities, ministries maintaining a register of recognised institutions.                                               |
| **Registry operator (LVC-2)** | Runs the credential registry that verifiers query.                                                   | A national examination board; a ministry data centre; an agency mandated by the ministry.                                                                       |
| **Governance body**           | Sets the rules for entering and leaving the trust registry and for resolving disputes.               | The ministry, or a qualifications authority acting under its mandate. Often the same organisation as the trust registry, but the roles should be kept distinct. |

Wallet providers, [identity providers](https://experience-digital-transform.gitbook.io/experience-digital-transformation/digital-identity-use-cases/) and consent services also appear in most deployments. They are consumed from the Wallet, Identity and Consent Building Blocks and are not defined here.

## 4.2 The trust problem

A verifier looking at a credential needs answers to three questions. Is the issuer real? A genuine organisation, not a diploma mill with a convincing name. Is the issuer authorised to issue this? A secondary school may issue leaving certificates but not degrees; a training provider may issue attendance certificates but not accredited qualifications. Is the credential itself intact and still valid? Unaltered since issuance, not revoked, not superseded. In education, these questions can be particularly complex because authority may be distributed across ministries, accreditation or qualifications bodies, examination authorities, schools, universities and training providers.

Today, most verifiers cannot answer these questions quickly, and many cannot answer them at all. Paper and plain PDF are easy to forge. Confirmation by email or telephone to the issuing institution does not scale, takes days, and depends on the institution still existing and answering. Lists of recognised institutions exist in most countries, but as documents for people to read, not as data for systems to query. Furthermore, recognition may depend on the type of credential, the period in which it was issued, and the authority under which it was issued. The body that accredits institutions is rarely the body that runs their signing infrastructure, so even where digital signatures are used, a signature proves that some key signed the document, not that the key belongs to an accredited institution with authority over that credential type.

Cryptography solves the third question, integrity, and does it well. It does not solve the first two. A valid signature from an unknown key proves nothing about who the issuer is or what it is authorised to issue. That gap is what a trust registry fills: an authoritative, machine-readable list of issuers, each with its scope of authority (which credential types, over which period, in which thematic area, what Qualification Framework level(s), and in which jurisdiction), governed by a body that has the legal or regulatory standing to decide who is on it. The registry is as much a governance artefact as a technical one; the hard part is not the data structure but agreeing who maintains it, on what criteria, and what happens when an institution closes, merges or loses accreditation.

Two situations make the problem sharper. Across borders, the verifier does not know the foreign issuers or the foreign accreditation system, so trust has to be established between registries, not between a verifier and an issuer. And for displaced learners, the issuer may be unreachable or may no longer exist, so the registry must preserve historical entries and the verifier must accept credentials issued during the period the issuer was authorised. The aim is therefore not only to verify credentials when the original institution is available, but also to preserve a credible way of establishing what was issued, by whom, and under what authority when circumstances change.

{% hint style="info" %}
Phase 1 of this specification does not design a global trust registry. It names the problem, gives one minimum trust arrangement per profile ([4.3](#43-trust-pattern-per-profile)), and points to systems that already operate each arrangement so that a country can learn from them.
{% endhint %}

## 4.3 Trust pattern per profile

| Profile   | Minimum trust arrangement                                                                                                                                          | Who governs it                                                          | What the verifier checks                                                                                                                   |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **LVC-1** | Published, machine-readable list of issuer signing certificates, with the credential types each may sign.                                                          | Education authority or national e-signature authority.                  | The signature validates against a certificate on the list, and the list entry covers this credential type on the date of issue.            |
| **LVC-2** | A single authoritative registry run by, or mandated by, the education authority; issuers onboarded by that authority.                                              | Education authority.                                                    | The registry returns a record matching the credential, from an issuer onboarded for this credential type.                                  |
| **LVC-3** | A machine-readable trust registry of accredited issuers, each with identifiers, keys and scope of authority, with governed entry and exit and a preserved history. | Accreditation or qualifications authority under the ministry's mandate. | Signature validates against a key in the registry; the issuer's scope covers this credential type on the issuance date; status is current. |

#### **Existing examples to learn from**

LVC-1: national e-signature frameworks and trusted lists; DC4EU classical PKI model. LVC-2: national examination boards' verification services; DigiLocker issuer onboarding (India); Sunbird RC. LVC-3: EBSI Trusted Issuers Registry; DC4EU hybrid X.509–DID model; national accreditation registers published as data.

In all three profiles the verifier must check scope, not only identity. A registry that says an issuer is genuine but not what it may issue leaves the second question in 4.2 unanswered. This is a functional requirement ([section 6.4](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/6.-specification.md)) for every profile.

#### **Two questions, two layers**

Trust arrangements answer two different questions and can use different mechanisms for each. "Who is this organisation" (issuer identity, verifier identity) is well served by conventional certificates and national trusted lists. "What may it do" (which credential types an issuer is authorised to award, what a verifier may request, what a holder may disclose) is a governance question that education systems answer through accreditation and data-protection rules, and it needs a registry that records authorisations, not just identities. DC4EU Pilot 2 implemented exactly this split: classical PKI for issuer and relying-party identity and a coarse control of what a relying party may request; EBSI-anchored identifiers and verifiable accreditations for the education-specific layer (issuer scope of authority, disclosure templates for holders, fine-grained disclosure policies for verifiers). A country can implement both layers on any technology; the point is not to collapse them into one.

#### Worked example: trust chains.

EBSI separates accrediting from issuing: a root accreditation organisation (typically a ministry) accredits sector accreditors (a quality-assurance agency, a VET authority, an examinations board), which accredit issuers, each accreditation being itself a credential with a scope and a validity period stored in a Trusted Issuers Registry. A verifier follows the chain upward and learns who authorised the issuer and for what. DC4EU implemented this for education with four quality-assurance credential types (institutional accreditation, programme accreditation, QA-agency recognition, register listing) as the accreditations. What transfers globally is the structure: three levels, accreditation as a record with scope and period, and a registry that keeps history. It can run on any registry technology, including a signed file published by the ministry.

Another example is how the European Learning Model, ELM describes accreditation, and applies the accreditation concept in the credentialing context. In the ELM Ontology, [Accreditation](https://europa.eu/europass/elm-browser/documentation/3-3-1/rdf/ontology/documentation/index-en.html#/Accreditation) is described as "The quality assurance or licensing of an organisation or a qualification. An accreditation instance can be used to specify information about: (1) the quality assurance and/or licensing of an organisation, (2) the quality assurance and/or licensing of an organisation with respect to a specific qualification." In the European Digital Credentials Application Profile the [Accreditation class](https://europa.eu/europass/elm-browser/documentation/3-3-1/rdf/ap/edc/documentation/edc-generic-no-cv_en.html#edcgn:AccreditationShape) has a handful of mandatory properties that must always be included in the accredited credential's metadata. These mandatory properties include the accreditation record's title, type, and a reference to the accrediting agent. Optional properties include the reference to the qualification that is accredited, the field of education for which an organisation is accredited to provide studies, the European Qualifications Framework levels for which an organisation is accredited to provide studies, the administrative territories in which the accreditation decision is valid, and a publicly accessible report of the quality assurance decision. Furthermore, to support transparency, interoperability and portability, many of these properties are informed by concepts from specific multilingual controlled vocabularies that are published as Linked Open Data.

The minimum retention period for historical registry entries, given that credentials are verified decades after issue. Two kinds of data need different rules: entries about issuers (identity, accreditation, scope of authority, validity periods) can be kept indefinitely so that historical credentials remain verifiable, whereas personal data about learners held by registries or verification services is subject to data-protection limits on retention (in the EU, for example, Article 12 of the proposed Skills Portability Act). The specification should keep the two apart.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.