> 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/3.-use-cases.md). # 3. Use Cases Seven use cases show how the three profiles work in practice. UC-01 to UC-05 are the anchor cases set out in the Terms of Reference, chosen to cover low-connectivity settings, population-scale issuance, labour mobility, displaced learners and learner-held credentials; UC-06 and UC-07 were added by the working group. Cards marked *Coming soon* will be completed in the next phase. | # | Use case | Profile | Status | | ----- | ---------------------------------------------------------------------------------------------------------------- | ------------ | ----------- | | UC-01 | Offline verification on a basic phone, with paper fallback | LVC-1 | Draft | | UC-02 | National exam results issued to all candidates via a registry | LVC-2 | Draft | | UC-03 | Worker's qualification checked by a foreign employer | LVC-2, LVC-3 | Coming soon | | UC-04 | Displaced learner whose school no longer exists | LVC-1, LVC-3 | Coming soon | | UC-05 | Learner-held diploma verified via a trust registry | LVC-3 | Draft | | UC-06 | Learner presents combined credentials for licensing, recognition, and employment | LVC-3 | Coming soon | | UC-07 | Learner pursuing upskilling or reskilling, or demonstrating their existing skills via European micro-credentials | LVC-2, LVC-3 | Draft | ### Existing use-case inventories DC4EU (36 institutions, 10 EU member states, 2023 to 2025) piloted one use case per credential type in its catalogue: fourteen learning credentials plus quality-assurance and identity types, each with a documented user journey and business rules. The issuance and verification pattern is the same for all; what changes is the data and the business rule. Piloted usage contexts by type: | Credential type | Piloted usage contexts | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Diploma, VET diploma, upper-secondary certificate | Employment verification; admission to further study; professional licensing; cross-border recognition | | Transcripts (higher education and upper secondary) | Admission with subject prerequisites checked automatically; credit transfer and advanced standing; course-by-course evaluation across national systems | | Diploma supplement | Recognition of a foreign qualification by an admissions office or recognition centre without contacting the issuer | | Proof of enrolment | Access to student services, housing, transport discounts and part-time work without repeated institutional contact | | Micro-credentials (higher education and VET) | Stacking toward a larger qualification; employer verification of a short course; prerequisite relationships between units | | Professional qualifications | Licence to practise checked by a foreign regulator or employer; continuing-education compliance | | Quality-assurance credentials | Automated check that the issuer was accredited for this programme on the issue date (feeds UC-04 and [Section 4](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md)) | Source: DC4EU educational-pilot repository, user journeys and sectorial rulebook (see [Section 8](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/8.-sources-and-standards.md)). ### UC-01 Offline verification on a basic phone, with paper fallback | | | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Use case** | UC-01 | | **Profile** | LVC-1 | | **Context** | This is a simple use case that is applicable across a wide spectrum of education credentials, and may be an approach of choice for several entities exploring digital credentials for the first time, given its relative ease of rollout. Applicable real-world scenarios may range from course completion credentials and skilling credentials from institutes to proof of student status. A few characteristics of scenarios where this would be applicable include: **Limited infra and resource availability** — best suited for environments operating in limited availability of digital infrastructure, lack of reliable connectivity, and learners/verifiers who rely on basic phones. **Quick, low-investment onboarding of a digital system of credentialing** — this profile offers the advantage of the least cost and complexity, and thereby the fastest time-to-market. This approach can be leveraged for roll-outs where getting a first version of digital credentials live in a time-bound manner is of essence. Example: a university digitises the certificates it issues so that learners have a verifiable digital copy of what would otherwise be a perishable paper document. | | **Who is involved** | **Issuer:** the institution, which signs each credential with a signing certificate that the education authority has listed. The credential can carry a QR code in one of two ways: (1) pointing to an online copy held by the issuer, verified online; or (2) containing the credential data itself, signed, in a published format, so that it can be verified offline. Either way the signature follows a standard (e.g., PAdES for PDF), so any verifier can check it with ordinary tools. The issuer also publishes a status list or status endpoint so that revoked credentials can be detected. **Education authority:** publishes and maintains the list of authorised issuers' signing certificates and what each may sign; this list is what tells a verifier that the issuer is genuine (see [4.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md)). **Learner:** receives the credential as a signed PDF and/or printed copy, and keeps it by email, on a drive or on paper. **Verifier:** checks the signature with a standard PDF reader, or scans the QR code with any conforming verification app (not one app per issuer), and checks the issuer's certificate against the authority's list. Variant (1) and up-to-date revocation checks need connectivity; variant (2) verifies offline. | | **What happens** | The education authority publishes its list of authorised issuers' signing certificates. The issuer creates the credential (for example, proof of student status, or a course-completion certificate with credits or scores), signs it, and adds the QR code. The learner receives the credential and stores it digitally or in print. The learner presents it to a verifier. The verifier checks the signature and the QR code with standard tools, confirms that the issuer's certificate is on the authority's list for this credential type and, where connected, checks its status. The verifier sees the whole credential; selective disclosure is not possible in this profile. | | **What if it goes wrong** | **Learner loses the physical copy of the credential** — the learner can access a soft copy that has been stored in their email/device and print a new copy. **Learner loses access to their soft copy** — the learner can request the issuer to send a copy via a channel of choice, by providing an identifier the issuer uses. **Issuer (say a university) closes** — new copies can no longer be issued, but existing credentials still verify if they used long-term signatures (e.g., PAdES-LT) and the authority keeps the issuer's certificate on its list with its validity period. **QR pointing to an online copy** — verification fails if the issuer's server is unavailable or the issuer no longer exists. **Issuer's certificate not on the authority's list** — verification fails, which is the correct outcome. **Offline verifier cannot reach the latest status list** — revocation cannot be detected, so the credential should be treated as unverified rather than valid. | | **Credentials and data used** | A signed, human-readable document (e.g., PDF/A), with a QR code that links to an online copy or carries the credential data in machine-readable form. The data covers the minimum elements in [5.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/5.-data-models.md); for a skills certificate, for example: learner's name, course, date, assessment result and issuing institution. Using a published format for the QR payload (such as a W3C Verifiable Credential or Open Badges 3.0) is what makes a later move to LVC-2 or LVC-3 a re-rendering rather than a re-issuance (see [2.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/2.-conformance-profiles.md)). | | **Standards referenced** | ETSI PAdES (signed PDF, including long-term validation); PDF/A; X.509 signing certificates and the education authority's published certificate list; for the QR payload, W3C VCDM or Open Badges 3.0; W3C Bitstring Status List or a status endpoint for revocation. | | **Education-system considerations** | Issuers need to be able to sign documents and generate QR codes, and the education authority needs to publish and maintain the certificate list; neither is a capacity common in many institutions. Simple, open-source, configurable tools, or a shared signing service run by the authority for smaller institutions, can unlock this use case. Because the document is an ordinary signed PDF, verifiers need no special software, which matters where employers will not install new tools. | ### UC-02 National exam results issued to all candidates via a registry | | | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Use case** | UC-02 | | **Profile** | LVC-2 | | **Context** | A national examination board publishes the results of a school-leaving or entrance examination for all candidates in the country, hundreds of thousands at a time, and employers, universities and scholarship bodies need to check them for years afterwards. The same pattern applies to a university graduation certificate, a skills certificate issued by a government skilling programme, or a professional qualification issued by a recognised body. Every credential is recorded in a registry run by, or on behalf of, the education authority; verification and revocation happen against that record, online. The registry is the single source of truth, so it must be maintained reliably over the long term. Trust moves from the issuer's signature to the registry and the authority behind it; this use case therefore presupposes a reliable governing body able to run the registry for as long as the credentials need to be verified. | | **Who is involved** | **Education authority:** mandates the registry and publishes how issuers are onboarded, how credentials are recorded, how learners access their copies and how verifiers query. **Registry operator:** runs the registry on the authority's behalf (often the examination board or a ministry data centre; see [4.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md)). **Issuer:** the examination board, university, skilling agency or professional body, onboarded by the authority, which creates each credential and records it in the registry. **Learner:** receives a copy (signed document, portal access, or both) and consents to verification. **Verifier:** employer, admitting institution or licensing body, which queries the registry rather than checking a signature. | | **What happens** | 1. The education authority mandates the registry and publishes the onboarding, access and verification processes. 2. Issuers are onboarded by the authority, with the credential types each may record. 3. The issuer generates each credential and records it in the registry; in the examination case, all results of a sitting at once. 4. The learner may retrieve or keep a copy by the access route the operator provides (portal, signed document with a QR code, or both). 5. Verification is triggered either by the learner presenting the copy to the verifier, or by the learner consenting to a verifier's query. 6. The verifier queries the registry online and receives the response the issuer has configured: the full record, a selected set of fields, or a simple valid/invalid answer. 7. The registry record is authoritative; if the learner's copy differs, the registry wins. | | **What if it goes wrong** | **The registry is unavailable** — no verification is possible during the outage, and there is no offline fallback. **The authority or operator ceases to exist and the registry with it** — issued credentials can no longer be verified, which is the main long-term risk of this profile (see [2.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/2.-conformance-profiles.md), long-term verifiability). **The registry record has been updated or revoked and no longer matches the learner's copy** — the verifier gets the current record, which is the intended behaviour. **An issuer not onboarded for this credential type submits a record** — the registry rejects it. **The registry operator can see who verifies whom and when** — a privacy consideration that LVC-2 must address through access rules and retention limits (see [2.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/2.-conformance-profiles.md), Privacy and Verifier controls). | | **Credentials and data used** | The authoritative record held in the registry, covering the minimum elements in [5.1](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/5.-data-models.md) (for an examination result: candidate, examination, subjects, grades, date, issuing board). Optionally, a signed human-readable copy (e.g., PDF/A) with a QR code that resolves to the registry record. Using a published format for the record and the QR payload (such as a W3C Verifiable Credential or Open Badges 3.0) makes a later move to LVC-3 a re-rendering rather than a re-issuance (see [2.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/2.-conformance-profiles.md)). | | **Standards referenced** | A registry query API published by the authority (verification by credential identifier, returning the configured fields); W3C VCDM or Open Badges 3.0 for the record and QR payload; the authority's published list of onboarded issuers; reference implementations: DigiLocker (India) and Sunbird RC (see [8](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/8.-sources-and-standards.md)). | | **Education-system considerations** | The authority needs the capability to set up the registry, keep it running for decades, and onboard issuers; this capacity is not common across institutions, which is why the registry is usually run centrally by an examination board or ministry rather than by each issuer. Verification is online only, so reliable connectivity for verifiers is a precondition. Because the operator sees every verification, access rules and retention limits for learner data are part of the design, not an afterthought. Where the authority publishes results at population scale, the registry must handle peak loads at results time. | ### UC-03 Worker's qualification checked by a foreign employer {% hint style="warning" %} *Coming Soon* {% endhint %} ### UC-04 Displaced learner whose school no longer exists {% hint style="warning" %} *Coming Soon* {% endhint %} ### UC-05 Learner-held diploma verified via a trust registry | | | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Use case** | UC-05 Learner-held diploma verified via a trust registry | | **Profile** | LVC-3 | | **Context** | A university graduate applies for a job with an employer in another country. Both parties have smartphones and normal connectivity; the employer has no relationship with the university and no way to call it. The graduate holds the diploma in a wallet on their phone. The issuing university and the employer's country both participate in a trust arrangement that lists accredited issuers. Piloted in the EU across higher education, VET and upper-secondary institutions; the same pattern applies wherever an accreditation authority can publish a machine-readable list of issuers. | | **Who is involved** | **Issuer:** the university (also the authentic source of the academic record). **Learner:** the graduate, using a wallet. **Verifier:** the employer's HR system or recruiter. **Trust registry:** an accredited-issuers registry maintained under the authority of the national accreditation or qualifications body. **Accreditation authority:** the body that entered the university in the registry and stated what it may issue. **Identity provider:** whoever issued the graduate's foundational identity credential, if the issuer requires identity binding at issuance. | | **What happens** | 1. Before any issuance, the accreditation authority records the university in the trust registry, with the credential types it may issue (for example, higher-education diplomas at a given level). 2. The graduate proves their identity to the university (in the pilot, by presenting a foundational identity credential; a national ID or existing student account can play the same role) and requests the diploma. 3. The university checks the academic record, builds the credential from it, signs it, and delivers it to the graduate's wallet. The credential carries the issuer's identifier, a reference to its schema, and a status reference. 4. The graduate applies for the job and presents the diploma from the wallet, choosing what to disclose (in the pilot, the full credential; with a suitable securing mechanism, selected fields only). 5. The employer's system checks the signature, resolves the issuer's identifier to its public key, confirms in the trust registry that the issuer was authorised to issue this credential type on the issue date, and checks the status reference. 6. The employer sees a verified result within seconds, without contacting the university. | | **What if it goes wrong** | **Issuer not in the registry** — verification fails with "issuer not authorised", which is the correct outcome and the main protection against diploma mills. **Credential revoked** (for example, after a proven academic fraud) — the status check fails. **Graduate has lost the phone** — the university re-issues from its records to a new wallet; nothing depends on the old copy. **University later closes** — the registry keeps the historical entry with its validity period, so credentials issued during that period still verify. **Verifier is offline** — it can verify if it has previously cached the registry entry, the issuer key and a recent status list; otherwise it must wait or fall back to a signed-document rendering if one was embedded. | | **Credentials and data used** | Diploma as a W3C Verifiable Credential using an education data model (in the pilot, the European Learning Model), with achievement title, level, awarding body, date, and a reference to the learner. Status list published by the issuer. Trust registry entry for the issuer with scope of authority. Optionally a foundational identity credential at issuance time. | | **Standards referenced** | W3C VCDM 1.1; W3C DIDs; European Learning Model v3.2 (data model); OpenID4VCI and OpenID4VP (issuance and presentation); W3C Bitstring Status List (status); EBSI Trusted Issuers Registry (registry pattern); JAdES and Data Integrity (securing). | | **Education-system considerations** | To work at scale this needs: (a) an accreditation authority willing to publish its register as data and to keep it current, including historical entries; (b) universities able to sign credentials and manage keys, or a shared signing service run for them; (c) a wallet available to graduates, which in most countries the education sector does not control; (d) a data model the country agrees on for the diploma, so that a foreign verifier can read it. Barriers seen in the pilot: institutions without key-management capacity; unclear legal standing of the digital credential relative to the paper one; verifiers unwilling to change their HR tooling; and the dependency on identity infrastructure at issuance, which delayed onboarding where national eID was not yet available. In the pilot, a hybrid trust model (classical certificates plus the decentralised registry) was chosen so that institutions could start from their existing signing certificates. | Evidence: DC4EU Pilot 2 ran this flow with 28 institutions in Belgium, Germany, Hungary, Italy, Lithuania, Poland, Portugal, Romania, Spain and Sweden using a hybrid trust model; three further institutions ran classical and decentralised infrastructures in parallel. The pilot treated the digital credential as an attestation with the same legal value as the original diploma, not as its replacement: the archived diploma remains the authentic record and the credential is a representation of it. That is the legal basis for the "add a representation, never invalidate one" principle in [section 2.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/2.-conformance-profiles.md). ### UC-06 Learner presents combined credentials for licensing, recognition and employment | | | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Use case** | UC-06 Learner presents combined credentials for licensing, recognition and employment | | **Profile** | LVC-3 | | **Context** | A working adult completes an emergency medical technician (EMT) programme at a community college while working part-time. To be certified and hired, they must show evidence held by several issuers: course completion and clinical hours from the college, a CPR certification from a separate training provider, and work history from a previous employer. Today each is a separate document checked separately, often by phone or email. Learners also routinely over-share, handing over a full transcript or ID to prove a narrow claim. In this use case the learner holds all of these in one wallet and presents the combination each verifier needs in a single transaction. The pattern applies wherever access to skilled or regulated work depends on education, training and work experience together: health, trades, apprenticeships and public-sector hiring. Assumes ordinary smartphone connectivity; the wallet may be native or web-based. | | **Who is involved** | **Issuers:** the college (Course Completion, Verified Experience Hours, Education Award Verification); a training provider (CPR certification); a previous employer (Employment Verification); and later the licensing body, which issues the licence. **Learner:** holds all credentials in one wallet. **Verifiers:** the licensing or certifying body, then an employer, possibly through its hiring system. **Trust registry:** lists each issuer and its scope of authority, including non-education issuers such as employers and training providers. **Governance body:** decides who may enter the registry and for which credential types. | | **What happens** | 1. Each issuer is entered in the trust registry with the credential types it may issue. An employer's scope covers employment records, not education awards. 2. The learner receives each credential as it is earned, over months or years. 3. The licensing body requests course completion, clinical hours and a current CPR certification in one request. The wallet shows the learner the full request, and the learner approves it. 4. The licensing body verifies each credential independently: signature, issuer scope on the issue date, and status, using only published status lists and the trust registry. It does not contact any issuer or query any learner record. 5. The licensing body issues the licence as a credential into the same wallet. 6. The employer requests the licence and employment history (role and dates only), not the transcript or date of birth. The learner reviews and approves. 7. The employer verifies each credential independently. No issuer learns that, when, or to whom its credential was presented. | | **What if it goes wrong** | **One credential has expired or been revoked** (for example, the CPR certification lapsed) — that credential fails, the others still verify, and the verifier sees which one failed and why. **An issuer is not in the registry for that credential type** — that credential fails as "issuer not authorised for this credential type", which is the correct outcome. **The verifier asks for more than it needs** — the learner sees the full request before presenting and can decline or present less; the verifier may not retain or infer beyond what was presented ([6.4](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/6.-specification.md), row 6). **A small employer cannot sign credentials** — a shared issuance service, a workforce board or a staffing intermediary issues on its behalf, within a registered scope. **The learner loses their phone** — each issuer re-issues from its records. **The learner has no smartphone** — each credential can fall back to a signed document (LVC-1), losing selective disclosure and the single combined presentation. | | **Credentials and data used** | Course Completion (course, hours, result), Verified Experience Hours (clinical hours, activity, supervising organisation), Education Award Verification (award without the underlying record), Employment Verification (role, organisation, dates), an industry certification (CPR) and the resulting licence. Each is a separate credential from its own issuer. The presentation bundles them without merging them, so each keeps its own issuer, evidence and status. Each verifier receives only the subset its decision requires. | | **Standards referenced** | W3C VCDM 2.0; Open Badges 3.0 (AchievementCredential) for course and certification credentials; W3C Verifiable Presentation; VCALM (VC-API) or OpenID4VP for multi-credential requests; W3C Bitstring Status List; W3C Data Integrity, including ecdsa-sd-2023 and BBS, for selective disclosure; trust registry pattern per [4.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md). | | **Education-system considerations** | (a) The trust registry must reach beyond education. Employers, training providers and licensing bodies need registry entries with their own scope, and the accreditation chain in [4.3](/experience-digital-transformation/dpi-for-education/learning-verifiable-credentials/specifications/4.-ecosystem-and-trust.md) does not cover them, so a separate route onto the registry is needed. (b) Licensing bodies must accept a digital credential as evidence under their own rules. This is a legal and policy change, not a technical one. (c) Employers will verify only if it costs them nothing to start: free, standards-based verification tools that need no integration or vendor relationship lower that barrier. (d) A combined presentation reveals more than any single credential and can be assembled into a profile of the learner. Minimum disclosure and the holder's approval of the full request matter more here than in single-credential cases. (e) The learners who most need combined credentials (career changers, workers without degrees, people with records) are often the most exposed to over-disclosure and the least likely to have a new device. The paper fallback and shared-device access should be designed in, not added later. | ### UC-07 Learner pursuing upskilling or reskilling, or demonstrating their existing skills via European micro-credentials | | | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Use case** | UC-07 Learners are pursuing upskilling or reskilling, or demonstrating their existing skills via European micro-credentials | | **Profile** | LVC-2, LVC-3 | | **Context** | A learner undertakes upskilling or reskilling through a short learning programme and obtains a European micro-credential. The learner wishes to demonstrate newly acquired or existing skills for employment, career progression, or further learning in another Member State. Micro-credentials support flexible lifelong learning pathways and skills portability across Europe. The 2022 Council Recommendation does not require micro-credentials to be digital. Its primary focus is on the content, quality, transparency, portability, and description of micro-credentials, not on mandating a digital format. The more recent Skills Portability Act, however, proposes that qualifications in scope, including micro-credentials where included in national qualifications frameworks, be issued as Digital Qualification Attestations through the EUDI Wallet and described using common standards such as the European Learning Model (ELM). | | **Who is involved** | Learner (credential holder), micro-credential provider/awarding body, accreditation or quality assurance authority, national qualifications authority, issuer of the digital qualification attestation, employer or employment service, Europass platform, and EUDI Wallet ecosystem participants. | | **What happens** | 1. The learner completes a micro-credential learning activity. 2. The learning provider issues a recognised micro-credential, ideally referenced to a National Qualifications Framework (NQF). Information about the qualification/learning opportunity is published via national qualification systems and Europass. 3. On request, the learner receives a verifiable digital qualification attestation in their EUDI Wallet and shares it with employers or other recipients. 4. Prospective employer, or other third-party actor, can verify the credential's authenticity and understand its learning outcomes and associated skills. | | **What if it goes wrong** | *(Not specified in this draft.)* | | **Credentials and data used** | The specifications for data fields in digital qualification attestations are detailed in Annex II to the Proposal for a Regulation of the European Parliament and of the Council on portability of qualifications and skills and amending Regulation (EU) 2018/1724 ("Skills Portability Act"). | | **Standards referenced** | European Qualifications Framework (EQF), National Qualifications Frameworks (NQFs), European approach to Micro-Credentials, Europass, European Learning Model (ELM), ESCO, EUDI Wallet/eIDAS framework, W3C Verifiable Credentials Data Model, ISCED-F classification, and Qualification Dataset Register-based publication mechanisms. | | **Education-system considerations** | Implementers of the European approach should observe the recommendations for qualification design, and inform the mandatory data fields in their published qualification/credential metadata, as specified in the Council Recommendation and Skills Portability Act Annexes. To maximise portability, micro-credentials should be quality assured, described through learning outcomes, linked where possible to European Qualification Framework levels and National Qualification Frameworks, published through interoperable qualification registers, and supported by recognition, validation, and lifelong learning policies. | --- # 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/3.-use-cases.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.