> 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/6.-specification.md).
# 6. Specification
The GovStack-format part. Phase 1 needs 6.1–6.3 and a first list of requirements; the rest is Phase 2.
## 6.1 Terminology
| Term | Definition |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Verifiable credential | A tamper-evident, cryptographically protected claim made by an issuer about a subject, checkable by a verifier. |
| Issuer | An organisation that creates, signs and manages credentials about learners, and keeps the records from which they can be re-issued. |
| Holder | The person who receives, keeps and presents a credential; in education, normally the learner. |
| Verifier | An organisation that checks a credential's integrity, the issuer's authority and the credential's status before relying on it. |
| Verifiable presentation | Data from one or more credentials that the holder shares with a verifier in a form the verifier can check. |
| Credential schema | A published, machine-readable definition of the structure and rules a credential of a given type must follow. |
| Credential status | Information published by the issuer telling a verifier whether a credential is valid, suspended or revoked. |
| Trust registry | An authoritative source that establishes which issuers are genuine and authorised. |
| Selective disclosure | Sharing only specific details of a credential rather than the whole credential. |
| Qualification | A specification of an assessment and validation process which is obtained when a competent authority determines that an individual has achieved learning outcomes to given standards. |
| Learning Outcome | A statement regarding what a learner knows, understands and is able to do on completion of a learning process, which are defined in terms of knowledge, skills and responsibility and autonomy. |
| Micro-credential | A quality-assured, learner-owned record of assessed, focused learning, smaller than a qualification, with standalone value and the ability to stack into larger credentials. |
| Accreditation | 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. |
| Regulated profession | A profession is regulated if a person has to hold a specific degree to access the profession, sit special exams such as state exams and/or register with a professional body before they can practise it. |
## 6.2 Key functionalities
{% hint style="warning" %}
Full information coming soon
{% endhint %}
| Functionality | What it lets people do |
| ----------------------------------- | ---------------------- |
| Issue | |
| Present | |
| Verify | |
| Manage status and revocation | |
| Check the issuer (trust registry) | |
| Manage credential types and schemas | |
## 6.3 Cross-cutting requirements
Only what is specific to learning credentials; general GovStack security and architecture rules already apply.
{% hint style="warning" %}
Full information coming soon
{% endhint %}
| Topic | What the LVC adds |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Security and keys | |
| Offline use and paper fallback | |
| Privacy | |
| Learners who are minors | |
| Verifiable for decades | |
| Languages and recognition | |
| Vendor neutrality | An issuing service SHALL produce credentials that a conforming learner wallet can receive and that an independent verifier can validate, without requiring a vendor-specific issuer–wallet–verifier arrangement. |
## 6.4 Functional requirements
One obligation per row. Level is REQUIRED or RECOMMENDED (GovStack 2.0).
| # | Requirement | Applies to | Level | Profile(s) |
| - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | ----------- | ------------------- |
| 1 | The verifier SHALL check that the issuer is listed in the trust arrangement of the profile and was authorised for this credential type on the issue date
| Verifier | REQUIRED | LVC-1, LVC-2, LVC-3 |
| 2 | A presentation MAY bundle credentials from distinct issuers, the verifier SHALL verify each credential independently, preserving its issuer and evidence | Verifier, wallet | RECOMMENDED | LVC-3 |
| 3 | Status and issuer authority SHALL be checkable from published status lists and trust registries, without a live query to the issuer or to any learner record | Verifier | REQUIRED | LVC-3 |
| 4 | The holder SHALL be shown, and SHALL approve, the full set of credentials and attributes requested before any presentation is made | Wallet | REQUIRED | LVC-3 |
| 5 | The verifier SHALL NOT retain or infer attributes beyond those presented and approved for the stated purpose | Verifier | REQUIRED | LVC-2, LVC-3 |
## 6.5 APIs, data structures and workflows (Phase 2)
Placeholders for Phase 2: OpenAPI definitions for issuance, verification, status, trust registry and credential types; detailed schemas; and diagrams for issuance, verification, revocation, issuer onboarding, recognition and offline verification.
{% hint style="warning" %}
*Coming Soon*
{% endhint %}
---
# 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/6.-specification.md?ask=&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.