> 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/ai-wallet-use-case/chapter-01-context-and-usecase.md). # Chapter 01: Context and Usecase AI-Enabled GovBuild Education Wallet Building Block This chapter establishes why the knowledge product exists and what it is for. It places the National Learner Registry (NLR) and Digital Credential usecase in the context of ITU's school-connectivity mission and the wider move towards Digital Public Infrastructure (DPI), describes the education credential problem and how the usecase solves it, walks through the five service journeys along with the actors involved, and explains why AI-readable skill files are the right tool to absorb the integration work.\ \ This knowledge product is intended for business developers and integrators, governments, ministries of education, digital transformation teams, DPI implementers, digital wallet solution providers, and development partners working to modernise education services. It is especially useful for countries looking to move from paper-based certificates and fragmented learner records to interoperable, wallet-based digital credential systems that can support enrolment, credential issuance, lifelong storage, and trusted verification across education, employment, and public services. Watch the demo: Understanding the AI Integration Assistant and Skills Marketplace {% embed url="" %} ## 1.1 ITU, DPI, and the education credentials #### 1.1.1 The role of ITU in school connectivity This is a joint International Telecommunication Union (ITU) and UNICEF initiative with a single, concrete goal: to connect every school in the world to the internet and every young person to information, opportunity, and choice. Once the connection exists, the value of that connectivity depends on the digital services that run over it and on whether those services can be trusted. Education is a foundational sector for any country’s digital government. A learner who can be uniquely identified, whose progress is recorded reliably, and whose qualifications can be issued and verified digitally is able to move through the education system and into employment with far less friction. Connectivity makes these services reachable; trusted digital infrastructure makes them dependable. The knowledge product addresses the layer that sits atop connectivity: the trusted issuance, storage, and verification of educational credentials. #### 1.1.2 Why trusted digital credentials matter after connectivity Most education credentials today are paper certificates and diplomas. They are slow to issue, easy to forge, expensive to authenticate, and difficult to verify across institutional or national borders. A graduate applying for a job abroad may wait weeks for a registrar to confirm a transcript by email or post. An employer has no reliable, low-cost way to check that a certificate is genuine and has not been revoked. Connectivity on its own does not solve any of this. Scanning a paper certificate and emailing the image simply moves an untrustworthy artefact faster. Trusted digital credentials change the economics. A credential issued as a cryptographically signed, machine-verifiable object can be checked by anyone, anywhere, in seconds, without contacting the issuer. The learner holds it, controls who sees it, and can present it for a lifetime. This is the difference between digitising paper and building genuinely trustworthy digital services. #### 1.1.3 The challenge of issuing, storing, and verifying education credentials at a national scale Doing this for a single institution is straightforward. Doing it for an entire country is hard for organisational and architectural reasons rather than cryptographic ones. National scale requires interoperability by design: * Identity: Millions of learners must be uniquely and consistently identified across schools, ministries, and time, including minors who depend on a guardian. * Issuance at volume: Many institutions must be able to issue legally valid, digitally signed credentials under a common trust framework and in accordance with national qualification rules. * Lifelong storage: Credentials must remain available to the learner and verifiable for decades, independent of whether the issuing institution still exists in its current form. * Verification by anyone: Employers, universities, and foreign agencies must be able to verify authenticity, integrity, issuer signature, and revocation status without bespoke integrations with each issuer. * Avoiding lock-in: If each ministry or vendor builds an island, credentials do not travel and the system fragments. #### 1.1.4 How wallet-based DPI building blocks address the challenge Digital Public Infrastructure (DPI) is the approach of building shared, reusable, interoperable components – identity, data exchange, payments, registries, consent, and digital wallets – that many services compose rather than rebuild. A digital wallet building block is the component that lets a learner hold their own credentials and present them to any verifier. Because the wallet, the issuer, and the verifier all speak the same open standards (W3C Verifiable Credentials carried over OpenID protocols), any conformant issuer can issue to any conformant wallet, and any conformant verifier can check the result. Point-to-point integration is not required. The GovStack Wallet Building Block specification defines a standard, vendor-neutral interface for exactly this, and the same open standards underpin parallel initiatives such as the European Digital Identity (EUDI) Wallet and W3C Verifiable Credentials. By implementing the education usecase as a wallet-based DPI building block aligned to GovStack, a country gets credentials that are portable, verifiable, and free of vendor lock-in and that can be reused beyond education in health, social protection, and professional licensing without re-architecting. This is the pattern the knowledge product will demonstrate. ## 1.2 The National Learner Registry and digital credentials The National Learner Registry (NLR) and digital credentials are foundational to enable a country to uniquely identify learners, manage their educational lifecycle, and issue, store, and share trusted digital credentials. It establishes a single source of truth for learner identities and qualifications, anchored in secure digital identity, consent-based data sharing, and legally valid digital signatures, and supports everything from a learner’s first enrolment to lifelong use of diplomas and certificates as verifiable credentials. The educational credentials in this usecase are modelled following the W3C CCG Verifiable Credentials for Education (vc-ed) task force, the reference specification set for education VCs, which aligns with Open Badges 3.0, Comprehensive Learner Records (CLR), and the W3C VC data model () {% embed url="" %} #### 1.2.1 Overview of the usecasess * Student registration and enrolment into the National Learner Registry (NLR) * Registration and issuance of certificates and diplomas as verifiable digital credentials. * Download and storage of credentials in a digital wallet. * Secure sharing and third-party verification of credentials with employers, universities, and agencies. * Credential revocation: see trust in action. The prototype demonstrates all five end-to-end usecases, using the issuer (Ministry of Education) and verifier (employer or university), as well as the learner-facing holder application (with digital wallet). #### 1.2.2 Key actors
ActorRole in the usecase
Student / Parent / GuardianSubject of the learner record and holder of the credentials; guardian acts for minors.
School / Institution Registration OfficerReviews flagged registrations, confirms prior education records, and validates applications.
Ministry of Education (MoE) RegistrarReviews and digitally signs enrolment decisions; the registry authority.
National Identity Provider (IdP)Authenticates learners and guardians; supplies verified identity attributes.
Digital Signature Authority / Trust Service Provider (TSP)Provides legally valid electronic signatures, institutional seals, and certificate validation.
MoE Credential Validation UnitVerifies academic completion and institutional signatures against the national qualification framework.
Data Protection AuthorityOversight of lawful, consent-based processing of learner data.
External relying partiesUniversities, employers, and agencies that verify credentials before accepting them.
#### 1.2.3 Preconditions * The learner or guardian possesses a national digital identity. * Educational institutions are registered and authorised in the Education Service Registry. * The platform is integrated with the relevant DPI building blocks: digital identity and authentication, document verification, consent management, digital signature and trust services, and payment services, where applicable. #### 1.2.4 End-to-end process overview The five usecases described below are demonstrated through the National Learner Registry and Education Wallet showcase. The guided walkthrough follows the interactions among the learner, the educational institution, the Ministry of Education (MoE), and an external relying party (RP) across registration, credential issuance, wallet storage, and verification. Usecase 1 - Register as a learner: The student or guardian authenticates through the education portal using their digital identity, and core attributes (name, date of birth, ID number, address, and guardian relationship for minors) are securely retrieved and pre-filled. They complete a standardised digital form covering personal details, school selection, and prior educational history. In the demo, the learner opens the National Education Portal, signs in with a compatible digital wallet, and scans the QR code. Presents the Person Identification Data (PID) to verify their identity. The learner then completes and submits the registration form.\ \ Usecase 2 - Review documents and enrol automatically: Identity and civil registry data are validated (manually for flagged cases), explicit and revocable consent is obtained for data use, and the application passes through a school-to-ministry approval workflow. The MoE Registrar digitally signs the enrolment decision, generates a Unique Learner Identifier (ULID), and creates the learner profile in the NLR. The learner is confirmed, and the profile becomes visible in their wallet. In the demo, the school officer reviews the learner’s application and validates the supporting documents. Once validation is complete, the NLR automatically enrols the learner, generates the ULID and creates a Student ID credential offer. Back on the National Education Portal, the learner scans the QR code and enters the transaction code to receive the credential in their wallet.\ \ Usecase 3 - Graduate, pay, and receive the diploma: The institution submits a digitally signed issuance request containing the learner’s ULID, programme details, grades, and outcome. The MoE Credential Validation Unit verifies academic completion and institutional signatures and checks compliance with the national qualification framework. Where a fee applies, payment is confirmed (simulated by a proof-of-payment workflow in the sandbox). The certificate or diploma is then issued as a verifiable credential, digitally signed by both the institution and the MoE, and registered in the National Certificate Registry. The school officer submits the learner’s graduation decision. The NLR automatically validates the institution and determines that the diploma fee is due. In the National Education Portal, the learner chooses to pay using either an account or a card payment credential. A single wallet interaction confirms the EUR 50 payment and delivers the diploma as a verifiable credential to the learner’s wallet. Usecase 4 - Apply for a job with your diploma: The learner unlocks the wallet with a PIN or biometrics, selects a specific credential, and chooses a sharing method (QR code, secure link, verifiable presentation, or API exchange). A clear consent prompt shows exactly which data fields are requested; consent is granted or denied, and the choice is logged. The Relying Party verifies the credential’s authenticity, integrity, the issuer's signature, and revocation status before accepting it, without contacting the issuer. In the prototype workflow demo, the learner opens the career portal, selects a role and applies using their wallet. The employer requests only five fields from the diploma, which the learner approves and shares. The portal verifies the qualification directly from the wallet and processes the application using the verified credential data. Usecase 5 - Credential revocation: When the issued diploma is revoked. The NLR processes the revocation immediately and permanently, making the diploma invalid. When the learner tries to apply again through the career portal using the revoked diploma, the application is rejected. The registry audit trail records the revocation along with the registrations, validations, enrolments, issuances, payments and credential verifications that occurred throughout the journey. ## 1.3 Why AI-assisted integration now #### 1.3.1 The integration problem, and what absorbs it The hard part of deploying wallet-based DPI is not the protocols. Wallet software providers have already implemented W3C Verifiable Credentials, OpenID4VCI, and OpenID4VP and expose these capabilities via documented OpenAPI endpoints. The hard part is the integration work. Reading the specifications and the provider’s API documentation, extracting the requirements that actually apply to this sector, writing the credential schemas and the code that calls the issuer, holder, verifier, and consent endpoints in the right sequence, and diagnosing the inevitable mismatches so that everything works end-to-end in a real education context. AI coding agents can now absorb this work. But the durable asset is not a single bespoke assistant tied to a vendor’s AI, a single model, or a single tool. The durable asset is a skill file: a portable, declarative capability package that the wallet software provider publishes and that any AI coding agent can install to learn how to integrate with a digital wallet. #### 1.3.2 Provider-published skill files A skill file is a self-contained bundle of the knowledge an agent needs to build against a wallet solution: the provider’s OpenAPI specifications, credential schemas, the protocol flows (issuance over OpenID4VCI, presentation over OpenID4VP), worked examples, sandbox and API-key setup steps, and the rules and guardrails for wiring the endpoints together. The wallet software provider authors and publishes the skill file alongside its developer APIs, keeping it in step with the APIs as they evolve. Implementers do not reverse-engineer the integration from documentation; they install the provider’s skill file and let their agent apply it. This inverts the usual model. Instead of every integrator re-deriving the same wiring, the party that knows the wallet best. The software provider encodes that knowledge once, in a form most agents can consume. The skill file is what lets an education application be scaffolded and launched in an accelerated timeframe rather than rebuilt from first principles. #### 1.3.3 A marketplace of skill files Skill files become most useful when they are not handed over one-to-one but published to a shared skills marketplace. In that model, any wallet solution provider can publish the skill files for its products, each one linked to the rulebooks and schema definitions it depends on the credential schemas, the national qualification and validation rules, and the trust-framework constraints. An implementer building a learning usecase browses the marketplace, installs the relevant provider’s skill file into their agent, and launches a working solution rather than starting from a blank page. The same marketplace lets a country compare providers on a like-for-like basis, swap one wallet provider’s skill file for another’s because both target the same open standards, and reuse a proven education skill file as the starting point for health, social protection, or licensing. This is the reusable, replicable packaging the knowledge product aims to demonstrate; the marketplace mechanism and its link to rulebooks and schemas are detailed in Chapter 2. #### 1.3.4 Agent-agnostic and model-agnostic by design The skill file is deliberately not bound to any one runtime or model. It is agent-agnostic: the same file installs into coding agents such as Claude Code, Codex, opencode, and Pi. It is model-agnostic: it relies on no model-specific feature, so it works with whichever large language model the agent runs on Claude, GPT, Qwen, or another capable model. The agent provides the runtime, the model provides the reasoning, and the skill file provides the wallet-specific, provider-maintained know-how. Because none of these three is locked together, governments and implementers avoid lock-in to a single AI vendor, model, or tool and can adopt the approach with whatever agent and model they already trust. #### 1.3. 5 Equal opportunity, no vendor lock-in, and digital sovereignty Because the skill file, the agent, and the model are kept separate and built on open standards, the approach is deliberately a level playing field rather than a captured one. ![The overall infrastructure](https://95341731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDXDTZNhGJPQlyqg12XmE%2Fuploads%2FG7P4vkTMWAURdnfOkWdZ%2Funknown.png?alt=media\&token=2c7f14f5-3e90-4309-9c12-1236fd71545d) * Equal opportunity for wallet providers: Any wallet solution provider, a small local vendor as readily as a large incumbent, can publish skill files to the marketplace and reach implementers on the same terms. Providers compete on the quality of their wallet and skill files, not on privileged access, so the market stays open to new and regional entrants. * No vendor lock-in: Skill files target open standards (W3C VC, OpenID4VCI/VP, GovStack Wallet BB) and the provider’s documented OpenAPI surface, so one provider’s skill file can be replaced with another’s that meets the same boundary conditions and will include clear exit options. * No AI, model, or tool lock-in: Nothing ties an implementer to a single AI vendor, model, or agent. A government can run the same skill file on an open-weight model such as Qwen inside an open-source agent such as opencode, or on a commercial model and agent, whatever it already trusts, can afford, or can host sovereignly. * Lower barrier to entry and digital sovereignty: A ministry or a small integrator can launch a working solution by installing a published skill file without a large systems-integration budget or dependence on one supplier’s roadmap. Combined with self-hostable wallets, open licences, and sovereign or hybrid cloud deployment, this lets countries retain control of their education data and infrastructure. This is the same equity logic that underpins Digital Public Infrastructure and ITU's mission: shared, open, reusable components that widen access rather than concentrate it. The marketplace, rulebooks, and schema mechanism that make this portability concrete are detailed in Chapter 2. #### 1.3.6 What skill files do well, and where human review is essential Skill-file-driven agents are strong at the high-volume, specification-driven work that dominates an integration: translating the provider’s OpenAPI endpoints and credential schemas into working calls, scaffolding the application code, and keeping artefacts consistent and reproducible from the same inputs. They compress weeks of careful but routine engineering into a guided, repeatable build. They are not left to run unsupervised. Every artefact an agent produces is reviewed by a qualified engineer before it is treated as a deliverable; AI-generated code is treated as a hypothesis until it has been validated against the working prototype and the provider’s sandbox; and prompts, agent runs, and reviewer trails are retained as audit evidence. Human judgement remains essential for design choices, security and privacy decisions, and final acceptance. This division of labour: skill-file-driven agents for absorption of integration work, and humans for review and accountability – is what makes the approach both fast and trustworthy, and it is detailed in Chapter 3. --- # 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/ai-wallet-use-case/chapter-01-context-and-usecase.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.