> 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/2.-conformance-profiles.md). # 2. Conformance Profiles This section is the core of the Phase 1 draft. A ministry should be able to read it and decide which profile, or which combination of profiles, fits its context. The three profiles are options, not levels. Each is independently valid, and a country can run more than one at the same time: for example, LVC-1 for a historical archive of diplomas, LVC-2 for national examination results, and LVC-3 for new higher-education qualifications that need cross-border recognition. What grows from LVC-1 to LVC-3 is the infrastructure a country needs to operate, not the value of the credential. ## 2.1 The three profiles | | LVC-1 Signed Document | LVC-2 Registry-Backed | LVC-3 Decentralised VC | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it is** | A digitally signed document (typically PDF) carrying a QR code that embeds, or links to, machine-readable data. No wallet needed. | A credential issued in an open, standardised format and recorded in a registry operated by, or on behalf of, the education authority. The verifier queries the registry. | A learner-held credential (W3C Verifiable Credential or equivalent) presented from a wallet and verified cryptographically. Issuer authority is checked against a trust registry. | | **How it is verified** | Signature check against the issuer's certificate. Works offline. The QR code may also point to an online copy for confirmation. | Query to the registry or to a hosted verification service. Online only. | Cryptographic check of signature, status and issuer authority. Works offline if issuer keys and a status list are cached. | | **Who you trust** | The issuer's signing certificate and the authority that issued or lists that certificate. | The registry operator, which must be the education authority or mandated by it. | Issuers listed in a trust registry governed by the education or accreditation authority. | | **Learner involvement** | None required. The learner receives a file and forwards it. | Optional. The learner may retrieve a copy; the verifier can query the registry directly with the learner's consent. | The learner holds the credential and decides what to present, to whom. | | **Privacy** | The whole document is shared. If the QR resolves online, the issuer's server may see who verifies. | The registry sees every verification. The whole record is usually returned. | The learner chooses whether to present the credential. Selective disclosure and unlinkability are possible where supported by the credential format and presentation design; verification must avoid revealing each use to the issuer. | | **Verifier controls** | None: anyone holding the document sees all of it, and the issuer cannot restrict who verifies. | The registry operator can control who may query and what is returned (e.g., registered verifiers, purpose-bound queries). | The holder sees and approves each request (required, see [6.4](https://app.gitbook.com/o/IXF49Y4h90pru8KEaSyA/sites/site_IU6Sc/s/oIuaYnEclr8uQFObkak8/~/edit/~/changes/38/learning-verifiable-credentials/specifications/6.-specification#id-6.4-functional-requirements)). Registration of verifiers and of the attributes each may request is recommended where a relying-party register exists. | | **Revocation** | Online, via a status endpoint referenced from the QR code. Not possible offline. | Immediate. The registry is the source of truth. | Via status lists published by the issuer. Cached lists allow offline checks with a delay. | | **Long-term verifiability** | Depends on long-term signature formats and certificate archiving (e.g., PAdES-LT); the document remains readable even if verification fails. | Depends on the continuity of the registry. If the registry disappears, so does verification. | Depends on issuer key history and status availability. The trust registry must keep historical entries for issuers that close or merge. | | **Cost / complexity** | Low. Signing certificates and a PDF signing tool. | Moderate. Registry operations, issuer onboarding, uptime. | Higher. Wallet ecosystem, key management, trust registry governance. | | **Best fit** | Low-resource or offline-first settings; contexts without a wallet ecosystem; legacy archives. | A single national or sectoral authority with reliable connectivity; results at population scale. | Cross-border recognition; learner-centric portability; privacy-sensitive presentations. | ## 2.2 Choosing a profile Most countries will find that different factors point to different profiles, depending on credential type and country context. This may mean running two profiles side by side, or starting with one and planning a move ([2.3](#23-moving-between-profiles)). Institutional capacity is often the deciding factor: a technically suitable profile that the responsible institutions cannot sustain in-house is not a good choice. | Factor | Guidance | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connectivity** | Where verifiers or learners regularly lack connectivity, LVC-1 is the most straightforward option, where credentials need to be verified fully offline. LVC-3 verifies offline once keys and a status list are cached, which suits verifiers with intermittent connectivity but not first-time verifiers. LVC-2 requires connectivity at every verification. | | **Device access** | LVC-1 needs nothing beyond a file viewer and a QR reader, and prints to paper. LVC-2 needs a browser or an API client on the verifier's side, nothing on the learner's. LVC-3 needs a wallet on the learner's device; where learners share devices or use basic phones, LVC-3 alone may create barriers to access. Profile selection should also consider who needs to access and verify the credential, not only the learner's access to technology. In some education systems, credentials may need to be verified by schools, employers, government agencies or other institutions with different levels of digital capacity. | | **Privacy needs** | Where a credential must be presented in part (proof of a degree without the transcript; proof of age without a birth date), only LVC-3 supports selective disclosure. LVC-1 shares the whole document. LVC-2 additionally exposes verification patterns to the registry operator, which may be a concern for sensitive uses such as licensing or immigration. | | **Cross-border recognition** | A foreign verifier can check an LVC-1 signature only if it can locate and trust the issuer's certificate; in practice this needs a published national list. LVC-2 requires the foreign verifier to know and trust the national registry. LVC-3 is designed for this case, provided the two countries' trust registries recognise each other. It is important to note that verifying that a credential is authentic does not by itself guarantee that a country or institution recognises the qualification. Recognition requirements may still need to be addressed separately (e.g. regional and global Learning Models). | | **Ecosystem maturity** | If there is no accredited-issuer list in machine-readable form, LVC-3 cannot be operated yet; LVC-1 with a published certificate list is the fastest route to something verifiable. If a national registry already exists (examination results, professional licences), LVC-2 builds on it. | | **Institutional capacity** | Consider whether the institutions responsible for issuing, maintaining and verifying credentials have the people, systems and processes needed to operate the profile over time. A technically suitable profile is only sustainable if the organisations responsible for it can maintain (in-house) required infrastructure, records, trust arrangements or support. | | **How current must the fact be** | Most credentials state something that was true at a point in time (a degree awarded, a course passed) and stay valid until revoked. Some questions are about the present (is this person enrolled today? do they currently hold a licence?). For these, LVC-2 answers by querying the registry directly; LVC-3 answers with short-lived credentials re-issued on demand (validity of a term or less), or with a freshness requirement on the status list; LVC-1 is a poor fit. Facts that change continuously and are computed rather than awarded (current credit total, progress toward a threshold) are data queries, not credentials, and belong with the [Education Data Building Block](/experience-digital-transformation/dpi-for-education/education-data.md). | | **Cost** | LVC-1 can be introduced institution by institution with commodity tools. LVC-2 concentrates cost in one operator and is cheapest per credential at scale. LVC-3 spreads cost across issuers (keys), a governance body (trust registry) and learners (wallets), and depends on a wallet ecosystem the education sector rarely controls. | A practical approach: answer the six factors for the credential types that matter most (for example, secondary-school leaving certificates and university degrees). Where the answers cluster around one profile, start there. Where they split, the split usually follows credential type, and different types can use different profiles. ## 2.3 Moving between profiles The guiding principle is add a representation, never invalidate one. Credentials already issued remain valid in the form they were issued. New representations are added, on demand or in bulk, from the issuer's own records, which remain the master. | Move | What changes | What happens to existing credentials | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **LVC-1 → LVC-2** | Credential data is captured in structured form ([5.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/5.-data-models.md)). A registry is set up or an existing one adopted. The QR code on new documents resolves to the registry record. A verification endpoint is published. | Remain valid as signed documents. Can be loaded into the registry from issuer records without re-issuance. QR codes on old documents keep working only if their original endpoint is preserved or redirected. | | **LVC-2 → LVC-3** | Issuers obtain signing keys and identifiers and are entered in a trust registry. Credentials are issued as VCs to learner wallets. The registry shifts from being the point of verification to being the issuer's record and status source. | Registry records can be re-issued as VCs on the learner's request ("upgrade on demand"). The registry stays available for verifiers that have not moved. No record expires because of the migration. | | **LVC-1 → LVC-3** | As above, combined. The signed document is kept as the human-readable rendering, embedded in or linked from the VC, so the PDF remains the fallback where wallets are absent. | Re-issued on demand from issuer records. Avoid mass re-issuance: it creates duplicate credentials with different identifiers and confuses verifiers. Where the LVC-1 document already carries a full VC in its QR payload, this move is a re-rendering of the same credential rather than a re-issuance. | Two consequences for all moves. First, the issuer's records must be kept in a form that allows re-issuance years later, which is a data-model requirement ([section 5](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/5.-data-models.md)) rather than a format one. Second, the trust registry introduced for LVC-3 must also list the certificates used under LVC-1 and the operator used under LVC-2, so that a verifier can check any generation of credential from one place. --- # 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/2.-conformance-profiles.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.