> 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-04-prototype-implementation.md). # Chapter 04: Prototype Implementation AI-Enabled GovBuild Education Wallet Building Block This chapter demonstrates how the AI Integration Assistant can accelerate standards-based system integration. Provider-published skills (Chapter 3) from the Giga Skills Marketplace guide an AI code-generation agent to scaffold integrations using wallet, consent, and identity building blocks, while a qualified system integrator reviews, tests, and accepts the generated artefacts. The education credentials scenario is the worked example, not the product objective: it shows how reusable, machine-readable guidance can reduce discovery and implementation effort, time and cost while keeping standards, specifications and validation evidence visible. The reference implementation connects the National Learner Registry (NLR), Wallet Building Blocks, a Consent Building Block, a National Identity Provider (IDP), a Trust Service Provider (TSP) and supporting registries. The Ministry of Education (MoE) uses provider services in the issuer role, the learner uses a compatible wallet in the holder role, and an external relying party uses provider services in the verifier role (chapter 2, section 2.7). The EUDI Wallet and the EU Business Wallet, or equivalent digital wallet and organisational wallet services, are showcase implementations, not mandatory products. A conformant alternative must still satisfy the applicable protocol, trust, assurance, security, operational and jurisdictional requirements. ![Figure 4.1. Prototype solution architecture: portals, the generated application backend, registries, the wallet building blocks, and DPI integration points. Dashed borders mark sandbox mocks.](https://95341731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDXDTZNhGJPQlyqg12XmE%2Fuploads%2FUmGoAbqpCEdg9mGs3ITL%2Funknown.png?alt=media\&token=cf5b81bb-6048-45fe-a30a-fc4d4b0cb135) ## 4.1 National Learner Registry Configuration #### 4.1.1 The learner registry schema The National Learner Registry is the system of record that gives every credential its learner-profile schema. The record is published as JSON Schema in the skill bundle and reproduced in Annex B and defines the following: * Unique Learner Identifier (ULID): Minted by the registry when the Ministry of Education (MoE) Registrar approves enrolment; every subsequently issued credential references it. * Core attributes: Name, date of birth, national identity link, address, and the guardian relationship for minors. * Institutional link: The school or institution the learner is enrolled with, validated against the Education Service Registry of authorised institutions. * Lifecycle events: Enrolment, transfer, completion, correction, and withdrawal, each recorded as a dated, attributable event. The schema is deliberately separable from the wallet layer, as required by the validation boundaries in Chapter 2 (Section 2.7.4). A country can localise the learner profile - its own identifiers, attribute set, and lifecycle rules - without touching the credential transport protocols. The usecases defined in Chapter 1 cover the following four journeys: Figure 4.2. The four service journeys as implemented in the prototype, end-to-end against real wallet software. #### 4.1.2 Registration forms and validation rules The journey 1 is realised as a low-code configuration rather than bespoke code. The student authenticates through the Education Portal with their digital identity, and verified attributes are securely retrieved to pre-fill the registration form: personal details, school selection, prior education history, and any special support needs, with supporting documents uploaded or referenced. Validation rules run at submission, identity and civil-registry consistency, institution authorisation, and completeness; and only flagged cases fall through to manual review by the School Registration Officer. Explicit, revocable consent for data use is captured at the point of submission (Section 4.4.2). #### 4.1.3 The school-to-ministry approval workflow Approved applications flow through a two-stage workflow that mirrors real administrative accountability. The School or Institution Registration Officer reviews flagged registrations, confirms prior education records, and validates the application. The MoE Registrar then reviews and digitally signs the enrolment decision, at which point the registry mints the ULID and creates the student profile. The learner is notified, and the profile becomes visible in their wallet. Rejections and requests for correction travel back through the same workflow, so every state change has a named actor. #### 4.1.4 Audit and traceability of registry changes Every registry event - registration, validation, approval, correction, credential reference - is logged with the event name, timestamp, actor identity, consent reference, and where applicable the digital signature, following the audit and evidence model of Chapter 2 (Section 2.7.4). The audit trail is what makes the registry usable as legal infrastructure rather than a database: any credential can be traced back to the signed decisions that produced it. ## 4.2 Credential Issuance #### 4.2.1 The issuance flow end-to-end Journey 2 runs from the institution to the learner's wallet in five steps: * Request: The institution as an actor submits a digitally signed issuance request carrying the learner's ULID, programme details, grades, and outcome. * Validation: The MoE Credential Validation actor verifies academic completion and the institutional signature, and checks compliance with the national qualification framework - encoded as the qualification rulebook in the skill bundle- so the rules are explicit, versioned, and reviewable rather than buried in code. * Payment: Where a fee applies, issuance is gated on payment confirmation, demonstrated in the sandbox by a proof-of-payment workflow rather than live financial transactions. * Issuance: The certificate or diploma is issued as a W3C Verifiable Credential in SD-JWT VC format, digitally signed by three actors: the institution, the MoE, and the trust service provider. * Registration: The issued credential is recorded in the National Certificate Registry with its type, status, and audit references, establishing the national record of the credential's lifecycle. #### 4.2.2 Credential schemas Three education credential types are modelled, following the W3C CCG Verifiable Credentials for Education (vc-ed) models and Open Badges 3.0 alignment established in Chapter 2 (Section 2.1):
Credential typeContentSchema artefacts
DiplomaQualification award: learner, institution, programme, qualification level, award date.diploma.schema.json (JSON Schema) with JSON-LD / Open Badges 3.0 mapping.
TranscriptDetailed academic record: courses, grades, credits, periods.transcript.schema.json with JSON-LD mapping.
Micro-credentialBounded achievement or short course completion.JSON Schema with Open Badges 3.0 achievement typing.
A provider skill package contains or references the machine-readable schema, credential metadata, protocol guidance, examples and validation criteria required for integration. Country overlays and qualification rules remain separately versioned localisation artefacts. The AI integration assistant uses the same pinned artefacts for generation and tests that are supplied to integrators and verifiers; a qualified system integrator must still confirm conformance, security and policy alignment. Full definitions are provided in Annex B. #### 4.2.3 Issuance implementation Mechanically, the issuer backend validates the request against the credential schema and qualification rulebook, then creates a credential offer against the Organisation Wallet Suite issuer API. The offer is returned to the learner as a QR code or deep link, which starts the OpenID4VCI flow; the wallet completes the token and credential-request steps. On the issuance webhook callback, the backend records the credential in the Certificate Registry. The skill's done-criteria apply before the flow is accepted: the credential is verified against the Verifier API, selective disclosure returns only the requested claims, and every call and its review are logged for audit purposes. ## 4.3 Digital Wallet Integration #### 4.3.1 Issuing to the learner's wallet Journey 3 begins when the learner authenticates, selects a wallet (the provider's Data Wallet in the prototype), and retrieves their active credentials from the Certificate Registry. Each credential is delivered over OpenID4VCI: the portal renders the credential offer as a QR code (scanned cross-device) or a deep link (same device), the wallet completes the issuance exchange, and the portal updates live - the issuance webhook is streamed to the browser over SSE, so the learner sees the credential arrive without refreshing. #### 4.3.2 Credentials in the wallet In the wallet, each credential is a cryptographically signed object bound to the learner's ULID. The wallet exposes the verification tools specified in the usecase: a QR code for presenting the credential, the signature chain showing the institutional and MoE signatures, and the live revocation status. The wallet is unlocked with a PIN or biometrics before any credential can be presented. #### 4.3.3 Selective disclosure, sharing, and third-party verification Journey 4 uses OpenID4VP with DCQL. The relying party - an employer or university running the EU Business Wallet as verifier - issues a presentation request that names exactly the credentials and claims it needs. The wallet shows the learner a clear consent prompt listing the requested fields; because the credential is an SD-JWT VC, the learner discloses only those fields, and the choice is logged. The verifier checks authenticity, integrity, issuer signature, and revocation status without contacting the issuer. The supported sharing methods are QR code, secure link, verifiable presentation, and API exchange. ## 4.4 DPI Integration Points The prototype composes the DPI building blocks defined in Chapter 2 (Section 2.3). Where a live national system is unavailable in the sandbox, a documented mock stands in, so each integration point below states both what runs in the sandbox and the pattern for a live deployment. #### 4.4.1 Digital identity Learners and officials authenticate via an OpenID Connect-style identity provider that also supplies verified attributes to pre-fill registration forms. The sandbox runs a mock national IdP; the integration pattern - authentication, attribute retrieval, and the binding of wallet credentials to the authenticated identity - is documented so a country substitutes its live national identity system without changing the application. #### 4.4.2 Consent management Consent is implemented with a Consent Building Block aligned with ISO/IEC 27560 (the prototype uses the example provider's implementation), driven by the consent skills of Chapter 3: learners are onboarded as Consent BB individuals, and consents are recorded against signed data agreements at every exchange - registration data use, issuance, and each presentation to a relying party. Consent is explicit, revocable, and logged; withdrawal and erasure are first-class operations, and consent references appear in the audit trail of every registry and credential event. #### 4.4.3 Digital signature and trust services The trust service provider supplies legally valid signing keys, institutional seals, and certificate validation. The trust list is configured in the Organisation Wallet Suite, so issuer and verifier identities are established before any credential is trusted, per the trust rulebook and the validation chain of Chapter 2 (Section 2.7.1). Institutional and MoE signatures are applied at issuance and validated at every verification. ## 4.5 Service Portal and User Experience #### 4.5.1 The learner portal The learner-facing web portal covers registration (Journey 1), credential retrieval into the wallet (Journey 3), and sharing (Journey 4). Wallet interactions centre on a consistent QR panel: provider logo in the centre, a success tick on completion, refresh on expiry, an open-in-wallet deep link for same-device flows, and a transaction code where the protocol requires one, so the learner meets the same interaction pattern at every step. #### 4.5.2 The institution portal The institution-facing portal serves the School Registration Officer and the issuing institution by enabling them to review flagged registrations, manage enrolments, and submit credential issuance requests. Issuance status updates arrive live over the same SSE stream that the learner portal uses, so an officer can watch a request move through validation, payment, and issuance without polling. #### 4.5.3 Look and feel, multi-channel access, and accessibility The user interface is built from a themed application shell with shared primitives and strings-driven internationalisation, so the entire surface can be re-branded and translated for a country deployment by editing theme tokens and string catalogues rather than components. The portal is responsive for mobile and desktop browsers, with the Data Wallet mobile app covering the learner's on-device journeys; contrast, keyboard navigation, and screen-reader labelling follow common accessibility guidance. ## 4.6 Integrating the Wallet into Your Own Application The prototype is a reference, not a destination: the same skills that built it integrate the Organisation Wallet Suite into an implementer's existing application. This section records the recommended path. #### 4.6.1 Two integration paths There are two ways to adopt the wallet capabilities, and the skills support both: * Scaffold, test, then transplant: Let the agent scaffold a standalone integration - backend proxy, webhook receiver, SSE stream, and a minimal UI - prove the journeys against a real wallet, then move the tested scaffolding into the production front-end and back-end. This is the lower-risk path and the one the prototype followed. * Integrate directly: Point the agent at the existing application front-end and back-end and let it wire the wallet flows in place. Faster when the application is small, or the team knows it well; the same review discipline applies to every diff. #### 4.6.2 Recommended sequence: use-case UI flow first The recommendation from the prototype build is to get the use-case UI flow right first, and only then integrate the API key and backend. The UI flow is where the journey logic and the consent semantics live - what the learner sees, when consent is asked, what the QR panel does - and it is the part domain stakeholders can review without reading code. Once the flow is fixed, the backend wiring is mechanical for the agent: the endpoints, sequences, and payloads all come from the skill. #### 4.6.3 The backend integration pattern Whichever path is taken, the generated backend follows a fixed security pattern: * A backend proxy hides the API key: The organisation API key from the wallet provider lives in backend configuration (for example .env) and never reaches the browser; the front-end talks only to the application's own backend. * Webhooks are HMAC-verified: Issuance, presentation, and revocation events arrive at a registered webhook endpoint and are verified before being trusted. * Events stream to the browser via SSE: The UI reflects wallet events live without polling. * A typed client and UI hooks wrap the surface: Front-end code calls a typed client rather than raw HTTP, keeping the integration reviewable and refactorable. #### 4.6.4 Enabling a wallet function, step by step Enabling a specific function - for example, issuance of a diploma credential - in an existing application looks like this: * Install the provider's skills into your agent (npx skills add or the .zip bundle from the marketplace). * Create the wallet-provider account and add the organisation API key only to the backend configuration. * Give the agent the layout of your UI, the usecase you are enabling, and the data schema and rulebook to apply. * State the goal and name the installed skill, for example: "Using the installed issuer skills, add diploma issuance to my enrolment app; show the offer QR on the confirmation page." * Answer the integrator intake (environment, API key location, tenancy, webhooks, front-end framework). * Review the diff the agent produces; treat it as a hypothesis until it passes. * Test the flow against the sandbox with a real wallet, then promote through staging to production. The same seven steps apply to verification and consent functions with the corresponding skills. Chapter 5 describes how the prototype and marketplace are deployed to the cloud sandbox, and Chapter 6 how the whole approach is replicated in another country context. \
--- # 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-04-prototype-implementation.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.