> 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-02-standards-and-architecture.md).

# Chapter 02: Standards and Architecture

AI-Enabled GovBuild Education Wallet Building Block

This chapter defines the technical foundation of the usecase. It sets out the standards stack the prototype is built on, and why each standard is used as a boundary condition (ref. 2.1), describes the wallet architecture and the roles of each component, maps the usecase onto the Digital Public Infrastructure (DPI) building blocks it integrates with, and explains how a digital wallet software provider’s OpenAPI endpoints are wired into an application through agent-agnostic, model-agnostic skill files. Together, these establish the interoperability boundaries against which the skill files, AI integration assistant (Chapter 3), and the prototype (Chapter 4) are validated.

## 2.1 Standards Stack

The architecture is standards-first; every inter-component contract is defined by an open specification from a recognised standards body, enabling any conformant issuer, wallet, or verifier to participate. These specifications are treated as boundary conditions - the assistant validates each tech provider’s issuer and verifier solution against them at the point it is connected to the integration assistant. Any provider meeting the boundary conditions can be substituted. The prototype is built on the following standards for key layers and roles.

<table data-header-hidden><thead><tr><th width="110.66668701171875"></th><th width="160.6666259765625"></th><th></th></tr></thead><tbody><tr><td>Layer</td><td>Standard</td><td>Role / Notes</td></tr><tr><td>Credential data model</td><td>W3C Verifiable Credentials Data Model 2.0</td><td>Primary format for education credentials; defines the structure and semantics of a verifiable credential.</td></tr><tr><td>Credential format</td><td>SD-JWT VC (IETF)</td><td>Selective disclosure of learner data - the holder reveals only the fields a verifier needs.</td></tr><tr><td>Issuance protocol</td><td>OpenID4VCI 1.0</td><td>Credential issuance from the issuer to the learner's wallet.</td></tr><tr><td>Presentation protocol</td><td>OpenID4VP 1.0 with DCQL</td><td>Credential sharing with verifiers; DCQL expresses exactly which credentials/claims are requested.</td></tr><tr><td>Education schema</td><td>W3C CCG VC for Education (vc-ed); Open Badges 3.0 (1EdTech)</td><td>Education credential modelling per the W3C CCG Verifiable Credentials for Education (vc-ed) models and usecases (https://w3c-ccg.github.io/vc-ed/); Open Badges 3.0 as the achievement type for certificates, diplomas, and micro-credentials.</td></tr><tr><td>Building block spec</td><td>GovStack Wallet BB</td><td>Vendor-neutral interface; OpenAPI contracts produced from a specs-as-code pipeline.</td></tr><tr><td>Wallet framework</td><td>EU Digital Identity Wallet (EUDI ARF)</td><td>Architecture and Reference Framework (ARF) alignment: the SD-JWT VC and OpenID4VCI/OpenID4VP rows above are part of the EUDI ARF protocol stack.</td></tr><tr><td>Consent management</td><td>ISO/IEC 27560</td><td>Learner-data consent records, aligned with the GovStack Consent BB.</td></tr><tr><td>APIs</td><td>OpenAPI 3.1</td><td>All wallet endpoints and inter-component contracts are described as OpenAPI 3.1.</td></tr><tr><td>Agent capability packaging</td><td>Agent-agnostic skill files</td><td>Provider-published bundle that teaches any AI integration assistance to integrate the wallet’s OpenAPI endpoints; portable across agents (Claude Code, Codex, Pi) and models (Claude, GPT, Qwen).</td></tr></tbody></table>

#### 2.1.1 How the standards stack is layered

The stack separates concerns so each standard can evolve independently:

* Data and format (what are credentials): W3C VC Data Model 2.0 defines the credential; SD-JWT VC defines how it is encoded, allowing the holder to selectively disclose individual claims; Open Badges 3.0 aligns the education-specific credential types with the W3C CCG Verifiable Credentials for Education (vc-ed) models.
* Protocol (how a credential moves): OpenID4VCI carries a credential from the issuer to the digital wallet at issuance; OpenID4VP carries a presentation from the wallet to the verifier at the time of sharing, with DCQL (Digital Credential Query Language) specifying the query.
* Interface and contract (how systems are wired): The GovStack Wallet BB specification provides the building-block interface, and every contract between components is published as an OpenAPI 3.1 specification. OpenID specifications act as the boundary validated during the first level of integration.
* Governance (lawful data use): ISO/IEC 27560 defines consent records that govern learner data sharing, implemented via the GovStack Consent BB.

Every layer is built on open standards; the assistant can validate any third-party issuer or verifier against the same boundary conditions, and the resulting credentials remain portable and verifiable independent of any single vendor. (The full requirement-to-standard-to-artefact mapping is provided in Annex A, the standards traceability table.)

## 2.2 Wallet Architecture Overview

The architecture follows the classic three-role verifiable-credential triangle: issuer, holder, and verifier - supported by trust, identity, consent, and registry services. In the prototype, the showcase uses an EUDI Wallet-compatible implementation for the learner and an organisational wallet for issuer/verifier functions; these are implementation options rather than mandatory choices configured for the education usecase.

#### 2.2.1 Components and roles

<table data-header-hidden><thead><tr><th width="117.33331298828125"></th><th width="125"></th><th></th></tr></thead><tbody><tr><td>Component</td><td>Plays the role of</td><td>Implementation in the prototype</td></tr><tr><td>EUDI Wallet app</td><td>Holder</td><td>Learner-facing wallet application that receives, stores, and presents credentials</td></tr><tr><td>EU Business Wallet</td><td>Issuer and Verifier</td><td>Issuer for the MoE Registrar; verifier for employers and universities (External relying parties)</td></tr><tr><td>National Identity Provider</td><td>Authentication</td><td>National digital identity for learners and guardians; mocked in the sandbox with a documented pattern for live national IDP (identity provider) integration.</td></tr><tr><td>Trust Service Provider</td><td>Trust anchor</td><td>Legally valid signing keys, institutional seals, and certificate validation.</td></tr><tr><td>Consent Service</td><td>Consent management</td><td>Explicit, revocable consent aligned with ISO/IEC 27560 (GovStack Consent BB).</td></tr><tr><td>Learner Registry &#x26; Certificate Registry</td><td>Systems of record</td><td>NLR holds learner profiles and ULIDs; Certificate Registry holds issued credentials.</td></tr></tbody></table>

#### 2.2.2 Architecture view (Figure 1)

At the centre, a learner (holder) uses the EUDI Wallet app. The MoE Registrar, which runs the EU Business Wallet as the issuer, issues credentials to the wallet app via OpenID4VCI after the learner authenticates through the identity provider and the credential is signed by the trust service provider. The learner registry supplies the ULID and profile; the certificate registry records issued credentials; the consent service governs every data exchange. When the learner shares a credential, a relying party acting as a verifier requests a presentation over OpenID4VP/DCQL, and the app returns a selectively disclosed SD-JWT VC that the verifier checks for authenticity, integrity, issuer signature, and revocation - without contacting the issuer.

![Figure 1: high-level architecture: education usecase, wallet building blocks, AI Integration Assistant, and brought-in foundation services \[The blue part is built during the ITU project\]](https://95341731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDXDTZNhGJPQlyqg12XmE%2Fuploads%2FVtCSNF6DvB7zos9yj4V0%2Funknown.png?alt=media\&token=cfceea26-67d7-43a8-855d-888ba09d5cee)

#### 2.2.3 Layered view

The same architecture can be read as four layers:

* Education usecase (prototype): Register learner in NLR, issue diploma credential, store in wallet, share and verify.
* Wallet building blocks: EUDI Wallet (holder) and EU Business Wallet (issuer + verifier) are configured with developer OpenAPI endpoints.
* AI Integration assistant layer (provider-published skill files): The wallet provider’s agent-agnostic, model-agnostic skill files, like OpenAPI specifications, credential schemas, protocol flows, and integration rulebooks, drive the layers above by teaching an agent how to wire the endpoints.
* Foundation (brought in, not built): The agent installs the skill file to build a wallet using the open-standards stack (W3C, OpenID4VC, SD-JWT VC, GovStack Wallet BB) and deploys on the International Telecommunication Union (ITU) cloud sandbox.

## 2.3 DPI Building Block Integration

The usecase is composed of DPI building blocks rather than a monolith. Each integration point below has a defined contract; where a live national system is not available in the sandbox, a mock or reference service that simulates the interaction is provided so the end-to-end journeys can still be demonstrated.

<table data-header-hidden><thead><tr><th width="94.6666259765625"></th><th width="223.33331298828125"></th><th></th></tr></thead><tbody><tr><td>Building block</td><td>What it provides in the usecase</td><td>Standard / boundary</td></tr><tr><td>Digital identity</td><td>Strong authentication of learners, guardians, and officials; retrieval of verified identity attributes to pre-fill registration.</td><td>National IDP (OpenID Connect-style); mocked in sandbox.</td></tr><tr><td>National Learner Registry</td><td>Learner profile creation and Unique Learner Identifier (ULID) management; lifecycle events.</td><td>Standardised learner data structures.</td></tr><tr><td>Consent management</td><td>Explicit, revocable learner consent is captured, enforced, and logged at every data exchange.</td><td>ISO/IEC 27560; GovStack Consent BB.</td></tr><tr><td>Digital signature &#x26; trust services</td><td>Legally valid credential signing, institutional seals, and signature validation.</td><td>GovStack e-signature / trust; standard or open-source e-signature implementations.</td></tr><tr><td>Information mediator</td><td>Secure, auditable data exchange between the learner registry, certificate registry, and verifiers.</td><td>X-Road-style mediator pattern; mock mediator in sandbox.</td></tr><tr><td>Digital wallet</td><td>Credential storage, presentation, and verification by the learner.</td><td>W3C VC, OpenID4VCI, OpenID4VP; GovStack Wallet BB.</td></tr><tr><td>Payments</td><td>Proof-of-payment workflow that gates credential issuance where a fee applies.</td><td>Simulated gateway / proof-of-payment in sandbox.</td></tr></tbody></table>

This building-block composition is what keeps the usecase modular, interoperable, and replicable: each block can be substituted with a country’s live national system without changing the others, because the contracts between them are the open standards defined in Section 2.1.

## 2.4 Provider-Published Skill Files and OpenAPI Integration

The architecture is wired together not by hand and not by a vendor-specific assistant, but by skill files that the wallet software provider publishes and that any AI integration assistant can install. This section describes that mechanism, and the OpenAPI surface it targets.

{% embed url="<https://youtu.be/7WCW3JsYkWI?si=jpi1zGxdA8lskx79>" %}

#### 2.4.1 The wallet provider’s OpenAPI surface

The wallet provider exposes its wallet capabilities as documented developer APIs (from the wallet SW stack provider). The endpoints relevant to this usecase are grouped as follows.

<table data-header-hidden><thead><tr><th width="104"></th><th width="280"></th><th></th></tr></thead><tbody><tr><td>API group</td><td>Purpose in the usecase</td><td>Standards/notes</td></tr><tr><td>Issuer APIs</td><td>Issue diplomas, transcripts, and micro-credential VCs from the MoE issuer to the learner wallet.</td><td>OpenID4VCI; W3C VC 2.0; SD-JWT VC.</td></tr><tr><td>Holder / Data Wallet APIs</td><td>Receive, store, and present credentials from the learner-held Data Wallet.</td><td>OpenID4VCI; OpenID4VP.</td></tr><tr><td>Verifier APIs</td><td>Request and verify presentations from relying parties (employer, university).</td><td>OpenID4VP with DCQL.</td></tr><tr><td>Trust Anchor APIs</td><td>Establish and resolve issuer/verifier trust.</td><td>Trust framework/ trust lists.</td></tr><tr><td>Wallet Provider APIs</td><td>Wallet instance lifecycle and attestation.</td><td>OpenID4VC wallet model.</td></tr><tr><td>Key Management APIs</td><td>Signing-key lifecycle for credential signatures.</td><td>-</td></tr><tr><td>Webhook APIs</td><td>Asynchronous callbacks for issuance, presentation, and revocation events.</td><td>-</td></tr><tr><td>Consent Management APIs (Admin &#x26; Individual)</td><td>Create and sign data agreements; let learners manage and revoke consent.</td><td>ISO/IEC 27560; GovStack Consent BB.</td></tr></tbody></table>

All groups are described as OpenAPI and protected by API-key authentication, with a sandbox for development. These OpenAPI endpoints are the concrete integration surface that the skill file targets, and they map directly onto the DPI building blocks in Section 2.3.

#### 2.4.2 Specs-as-code: what the agent reads

The OpenAPI specifications, JSON Schema credential definitions, and machine-readable rulebooks bundled in a skill file are this project’s specs-as-code: published standards and API contracts rendered into machine-readable artefacts an agent can act on directly (the methodology’s “translate specifications into machine-readable formats” step). They are the durable, regenerable representation of the standards - not prose to be interpreted by hand.

The skill file does not replace specs-as-code; it packages it and adds the instructions, ordering, and guardrails that tell the agent how to turn those artefacts into a working integration (the code-generation and interoperability steps). In short, specs-as-code is what the agent reads; the skill file is that plus how the agent should use it. A country can regenerate the specs-as-code artefacts as standards evolve, while the same skill file orchestrates their use across any agent and model.

#### 2.4.3 What a skill file contains

A provider-published skill file bundles everything an agent needs to integrate the surface above without re-deriving it from prose documentation:

* The OpenAPI specifications for the issuer, holder, verifier, consent, and supporting endpoints.
* The credential schemas for the education credential types (diploma, transcript, micro-credential) are in JSON Schema and JSON-LD.
* The protocol flows as ordered, executable steps: issuance over OpenID4VCI, presentation over OpenID4VP/DCQL, consent capture over the Consent APIs.
* Set up steps for API keys and the sandbox, plus worked examples and request/response samples.
* Rules and guardrails: required headers, error handling, idempotency, and validation checks; integration must pass.

#### 2.4.4 How it is used to accelerate an application

An implementer installs the skill file into the AI integration assistant of their choice. The agent, running on whatever model it is configured with, reads the skill file and scaffolds the integration: it generates the calls to the issuer, holder, verifier, and consent endpoints in the correct sequence, wires them into the four service journeys, and produces the application code and configuration. Because the provider keeps the skill file aligned with its live API, the generated integration tracks the real endpoints rather than a stale snapshot. This is what allows an education application to be launched in an accelerated timeframe.

#### 2.4.5 Agent-agnostic and model-agnostic boundaries

Three concerns are kept separate so none lock in the others. The skill file (published and maintained by the wallet provider) carries the wallet-specific know-how. The agent (Claude Code, Codex, opencode, Pi, or another) provides the runtime that installs and executes the skill file. The model (Claude, GPT, Qwen, or another) provides the reasoning. A government or implementer can therefore adopt the approach with the agent and model they already trust, swap any of the three independently, and still target the same OpenAPI boundary conditions defined in Section 2.1. Governance of these AI-generated artefacts - review, validation, and audit trails - is covered in Chapter 3.

## 2.5 The Skills Marketplace

Skill files reach their full value when they are published, discovered, and reused through a shared skills marketplace rather than exchanged privately. The marketplace is the distribution and governance layer for the approach.

#### 2.5.1 What the marketplace does

* Provider publication: Any provider- for example, an EUDI Wallet provider - can publish the skill files for its issuer, holder, verifier, and consent products, each versioned and tied to a specific release of its OpenAPI surface.
* Discovery and reuse: An implementer building an education (or other sector) usecase browses the marketplace, installs the relevant skill file into their agent, and launches a working integration. The marketplace turns “read the docs and integrate” into “install and build”.
* Composed artefacts: Each published skill file declares the artefacts it depends on and links to them, so installing a skill file also brings in the rules and data shapes it needs.

#### 2.5.2 Skill files, rulebooks, and schemas

Three artefact types are composed in the marketplace, mirroring the Ai integration assitance layer in the architecture (schemas and rulebooks driving the wallet building blocks):

<table data-header-hidden><thead><tr><th width="95.33331298828125"></th><th width="156"></th><th></th></tr></thead><tbody><tr><td>Artefact</td><td>What it is</td><td>Example in this usecase</td></tr><tr><td>Schema definition</td><td>The data shape of a credential or registry record, in JSON Schema (and JSON-LD where required).</td><td>Diploma, transcript, and micro-credential schemas; the NLR learner-profile / ULID schema, derived from the credential schema library.</td></tr><tr><td>Rulebook</td><td>Machine- and human-readable rules and policies that an integration must honour.</td><td>National qualification-framework validation rules, credential validity and revocation rules, trust-framework and issuer-authorisation rules, consent (ISO/IEC 27560) rules.</td></tr><tr><td>Skill file</td><td>The capability package that teaches an agent to call the wallet’s OpenAPI endpoints, referencing the schemas and rulebooks above.</td><td>“Issue an education credential with the integrated vendor’s APIs.”</td></tr></tbody></table>

Separating these means a country can localise the rulebook (its own qualification framework) and the schema (its own credential fields) while reusing the provider’s skill file unchanged - and a provider can update its skill file when its API changes without disturbing a country’s rules.

#### 2.5.3 Governance and sustainability

Because the marketplace is the point of publication, it is also where provenance and trust live: each skill file carries its provider, version, target API release, and licence, and is reviewed before it is treated as a deliverable (Chapter 3). This aligns with the Knowledge Product’s replication and sustainability goals - artefacts published under open licences (CC BY 4.0 for content, Apache 2.0 for code), with repository stewardship under ITU - so that the education skill files, rulebooks, and schemas remain reusable starting points for other countries and sectors.

## 2.6 Installing and Using Skill Files Across Agents

A skill file is a portable bundle. The same bundle installs on different agents via a thin, per-agent step; its contents do not change.

#### 2.6.1 Bundle layout

A typical skill bundle published to the marketplace looks like this:

`igrantio-education-issuer-skill/`\
`SKILL.md # manifest + instructions (the entry point)`\
`openapi/`\
`issuer.yaml # iGrant.io Issuer API (OpenAPI 3.1)`\
`holder.yaml # Data Wallet API`\
`verifier.yaml # Verifier API`\
`consent.yaml # Consent Management API`\
`schemas/`\
`diploma.schema.json # credential schema definitions`\
`transcript.schema.json`\
`learner-profile.schema.json`\
`rulebooks/`\
`qualification-rules.md # validation / trust / consent rules`\
`examples/`\
`issue-diploma.http # worked request/response samples`

#### 2.6.2 Per-agent installation

The marketplace provides a copy-paste install snippet for each supported agent; the patterns are:

<table data-header-hidden><thead><tr><th width="102.66668701171875"></th><th></th></tr></thead><tbody><tr><td>Agent</td><td>How a marketplace skill is installed</td></tr><tr><td>Claude Code</td><td>Add the marketplace: /plugin marketplace add &#x3C;marketplace-repo>, then install the skill as a plugin:/plugin install igrantio-education-issuer. Alternatively, drop the bundle into .claude/skills/ (project) or ~/.claude/skills/ (personal); it auto-loads by its description.</td></tr><tr><td>opencode</td><td>Register the bundle in opencode.json (as an instructions/rules path or plugin) and expose openapi/*.yaml to the agent; opencode loads it for the session.</td></tr><tr><td>Codex CLI</td><td>Reference the bundle from the project’s AGENTS.md (point to SKILL.md and the openapi/ specs), or attach the OpenAPI specs via an MCP server in ~/.codex/config.toml.</td></tr><tr><td>Pi (and other agents)</td><td>Place the bundle in the agent’s skills/rules directory, or load it via MCP; any agent that can read a Markdown manifest plus OpenAPI files can consume it.</td></tr></tbody></table>

The exact command differs per agent and version, but the contract is the same: the agent reads SKILL.md, loads the referenced OpenAPI specs, schemas, and rulebooks, and uses them to generate and run the integration. When an agent supports the Model Context Protocol (MCP), the provider can also expose the same OpenAPI surface as an MCP server, allowing the agent to call the endpoints directly during the build.

#### 2.6.3 Sample skill file (SKILL.md)

\---\
`name: itu-giga-education-issuer`\
`description: >`\
`Integrate education credential issuance (diploma, transcript,`\
`micro-credential) against the iGrant.io Issuer API using OpenID4VCI.`\
`Use when an application must issue W3C Verifiable Credentials to a`\
`learner's wallet.`\
`version: 1.0.0`\
`walelt sw provider: iGrant.io, Sweden (LCubed AB)`\
`targets:`\
`api: https://docs.igrant.io/docs/developer-apis`\
`openapi: ./openapi/issuer.yaml`\
`protocols: [OpenID4VCI-1.0, W3C-VC-2.0, SD-JWT-VC]`\
`depends_on:`\
`schemas: [./schemas/diploma.schema.json, ./schemas/transcript.schema.json]`\
`rulebooks: [./rulebooks/qualification-rules.md]`\
`auth: API key (X-API-Key header); use the sandbox base URL for development`\
license: Apache-2.0\
\---\
\
\# Issue an education credential (iGrant.io Issuer API)\
\
\## When to use\
Use this skill when the application must issue a signed education\
credential to a learner's wallet and register it for later verification.\
\
\## Prerequisites\
1\. Obtain an API key and the sandbox base URL (see the provider's\
"Get Started with APIs").\
2\. Confirm the learner has a ULID in the National Learner Registry.\
\
\## Steps\
1\. Validate the issuance request against \`schemas/diploma.schema.json\`\
and the rules in \`rulebooks/qualification-rules.md\`.\
2\. Create a credential offer: \`POST /issuer/credential-offer\`\
(see \`openapi/issuer.yaml\`) with the learner DID, credential type,\
and claims.\
3\. Return the offer to the wallet to start the OpenID4VCI flow; the\
wallet completes the token and credential-request steps.\
4\. On the issuance webhook callback, record the credential in the\
Certificate Registry.\
\
\## Validation / done criteria\
\- The credential verifies against the Verifier API.\
\- Selective disclosure (SD-JWT VC) returns only the requested claims.\
\- Every call and its review are logged for audit (see Chapter 3).

This sample is illustrative; the authoritative manifest, OpenAPI specs, schemas, and rulebooks are the ones the provider publishes to the marketplace and keeps in step with its live API.

## 2.7 Architecture Validation Boundaries

The proposed architecture uses the Integration Assistant as a validation and assembly layer. The assistant does not accept a provider integration merely because endpoints exist. It evaluates the provider against explicit boundary conditions: GovStack Wallet BB roles, OpenID protocol behaviour, OpenAPI contracts, NLR application specifications, schemas, and rulebooks. In the software supply chain, outdated, incomplete, incompatible, or incorrectly configured inputs can cause integrations to fail, behave inconsistently, or diverge from expected standards and interfaces. Changes in upstream APIs, schemas, dependencies or provider implementations can also introduce compatibility issues.

#### 2.7.1 Validation chain

<table data-header-hidden><thead><tr><th width="104.66668701171875"></th><th width="149"></th><th></th></tr></thead><tbody><tr><td>Validation stage</td><td>Boundary input</td><td>Acceptance condition</td></tr><tr><td>1. Provider role mapping</td><td>GovStack Wallet BB specification</td><td>Provider issuer, holder, and verifier capabilities map to the Wallet BB roles and required interfaces.</td></tr><tr><td>2. First-level protocol validation</td><td>OpenID4VCI for issuance; OpenID4VP with DCQL for presentation</td><td>Issuer and verifier flows pass the OpenID boundary before provider-specific extensions are used.</td></tr><tr><td>3. API contract validation</td><td>OpenAPI 3.1 specs, JSON Schema, examples, sandbox URLs, and authentication scheme</td><td>The assistant can generate calls, validate requests/responses, and capture repeatable evidence.</td></tr><tr><td>4. Credential and presentation validation</td><td>W3C VC Data Model 2.0, SD-JWT VC, Open Badges 3.0, presentation definitions</td><td>Credentials remain portable, selectively disclosable, and understandable by conformant verifiers.</td></tr><tr><td>5. Application-layer validation</td><td>NLR, Certificate Registry, Education Service Registry, consent, audit, and workflow specs</td><td>The education journey works end-to-end without hard-coding national policy into provider APIs.</td></tr><tr><td>6. Rulebook validation</td><td>Qualification, issuer-authorisation, guardian consent, revocation, payment, retention, and trust rules</td><td>Country-specific rules are explicit, reviewable, versioned, and separable from the wallet provider.</td></tr></tbody></table>

#### 2.7.2 Boundary-condition standards

<table data-header-hidden><thead><tr><th width="109.33331298828125"></th><th width="169"></th><th></th></tr></thead><tbody><tr><td>Boundary area</td><td>Standards/specifications used</td><td>Role in the architecture</td></tr><tr><td>Wallet building block</td><td>GovStack Wallet Building Block Specification</td><td>Vendor-neutral validation point for any issuer, holder, or verifier provider connected to the Integration Assistant.</td></tr><tr><td>Issuance protocol</td><td>OpenID for Verifiable Credential Issuance (OpenID4VCI)</td><td>First-level integration boundary for issuing credentials from the MoE issuer to the learner wallet.</td></tr><tr><td>Presentation protocol</td><td>OpenID for Verifiable Presentations (OpenID4VP) with DCQL</td><td>First-level integration boundary for verifier requests, selective disclosure, and learner-controlled presentation.</td></tr><tr><td>Credential model and format</td><td>W3C Verifiable Credentials Data Model 2.0; SD-JWT VC</td><td>Defines credential semantics and holder-controlled selective disclosure.</td></tr><tr><td>Education credential semantics</td><td>W3C CCG VC for Education (vc-ed) and Open Badges 3.0 / 1EdTech alignment</td><td>Provides education-specific vocabulary for certificates, diplomas, transcripts, and micro-credentials.</td></tr><tr><td>API contract</td><td>OpenAPI 3.1; JSON Schema 2020-12</td><td>Machine-readable input used by the assistant to create, test, and validate integrations.</td></tr><tr><td>Identity and access</td><td>OpenID Connect / OAuth 2.0 style authentication profile, as applicable to the national IDP</td><td>Authenticates learners, guardians, officials, and relying parties before wallet or registry operations.</td></tr><tr><td>Consent</td><td>ISO/IEC 27560 consent record structure</td><td>Explicit, revocable consent for learner data sharing and verifier disclosure.</td></tr><tr><td>Data exchange and trust</td><td>Information mediator / API gateway pattern; X-Road-style auditable exchange was used</td><td>Defines secure exchange between registries, trust services, wallet providers, and relying parties.</td></tr><tr><td>Operational assurance</td><td>ISO 27001, ISO 27017, and ISO 27018 as reference controls were adopted</td><td>Supports security, cloud operations, and privacy assurance for production deployment.</td></tr></tbody></table>

#### 2.7.3 OpenAPI specification input

The OpenAPI package is a required input to the Integration Assistant. It is not a descriptive appendix; it is the machine-readable contract used to wire the solution. A provider package must include the issuer, holder/data-wallet, verifier, consent, trust-anchor, key-management, webhook, and supporting API groups that are relevant to the selected deployment scope.

<table data-header-hidden><thead><tr><th width="106"></th><th></th><th></th></tr></thead><tbody><tr><td>OpenAPI input</td><td>Minimum content</td><td>Validation performed by the assistant</td></tr><tr><td>Issuer API</td><td>Credential-offer, issuance, status, webhook, error, and authentication operations</td><td>Maps to OpenID4VCI, credential schema, issuer authority, signing, and certificate-registry recording.</td></tr><tr><td>Holder / EUDI Wallet API</td><td>Wallet binding, credential receipt, storage, presentation, status display, and consent operations</td><td>Confirms the learner can receive, store, unlock, and present credentials using the selected wallet.</td></tr><tr><td>Verifier API</td><td>Presentation request, DCQL query, response verification, status/revocation check, and audit result</td><td>Maps to OpenID4VP/DCQL and verifies authenticity, integrity, issuer signature, and revocation status.</td></tr><tr><td>Consent API</td><td>Data-agreement, consent grant, revocation, receipt, and audit endpoints</td><td>Checks that data sharing is explicit, revocable, logged, and connected to ISO/IEC 27560 records.</td></tr><tr><td>Trust and key APIs</td><td>Issuer trust, verifier trust, signing-key lifecycle, certificate validation, trust-list resolution</td><td>Confirms that the issuer and verifier identity can be established before credentials are trusted.</td></tr><tr><td>Sandbox and evidence</td><td>Base URLs, API-key/OAuth profile, examples, test credentials, conformance outputs, logs</td><td>Let the assistant produce repeatable integration evidence and human-review artefacts.</td></tr></tbody></table>

#### 2.7.4 Application / NLR layer specifications

The National Learner Registry is the application layer that gives the wallet flow its educational meaning. The relevant specifications must be provided separately from wallet-provider APIs so that a country can localise the education model without changing the credential transport protocol.

<table data-header-hidden><thead><tr><th width="123.33331298828125"></th><th></th><th></th></tr></thead><tbody><tr><td>Application spec</td><td>What it defines</td><td>Why it matters</td></tr><tr><td>NLR learner profile</td><td>ULID, identity link, name, date of birth, guardian relationship, school, enrolment state, lifecycle events</td><td>Creates the authoritative learner record that credentials refer to.</td></tr><tr><td>Education Service Registry</td><td>Authorised schools, institutions, programmes, issuing roles, and registration officers</td><td>Controls who can enrol learners and request the issuance of credentials.</td></tr><tr><td>Certificate Registry</td><td>Credential record, issuer, credential type, issuance status, revocation/status state, expiry, audit references</td><td>Provides the national record of issued credentials and their lifecycle.</td></tr><tr><td>Workflow definitions</td><td>Registration form, document checks, school-to-ministry approval, payment gate, exception handling</td><td>Connects the service journeys to executable low-code or configured workflows.</td></tr><tr><td>Consent and disclosure policy</td><td>Permitted purposes, data minimisation, revocation, guardian/minor handling, relying-party purpose</td><td>Ensures learner-controlled sharing and privacy-preserving verification.</td></tr><tr><td>Audit and evidence model</td><td>Event names, timestamps, actor IDs, consent references, signatures, validation results, logs</td><td>Creates traceability for procurement review, operational audit, and future replication.</td></tr></tbody></table>

#### 2.7.5 Schema definitions and rulebooks

<table data-header-hidden><thead><tr><th width="94.66668701171875"></th><th></th><th></th></tr></thead><tbody><tr><td>Artefact</td><td>Required examples</td><td>Boundary role</td></tr><tr><td>Schema definitions</td><td>NLR learner profile, diploma, certificate, transcript, micro-credential, consent record, presentation request, audit event</td><td>Define the data shape that OpenAPI requests, credentials, registries, and verifier presentations must satisfy.</td></tr><tr><td>Credential schemas</td><td>JSON Schema and JSON-LD / Open Badges 3.0 mappings (per the W3C CCG vc-ed models) for each education credential type</td><td>Ensure credentials are machine-verifiable and semantically understandable across wallets and verifiers.</td></tr><tr><td>Protocol profiles</td><td>OpenID4VCI issuer profile, OpenID4VP/DCQL verifier profile, selected SD-JWT VC disclosure profile</td><td>Constrain the standards to the exact options used in the demonstrator and conformance checks.</td></tr><tr><td>Rulebooks</td><td>Qualification-framework rules, issuer-authorisation rules, credential lifecycle, revocation/status, guardian consent, payment, retention, trust</td><td>Keep policy decisions reviewable and swappable rather than embedding them in provider-specific code.</td></tr><tr><td>Skill files</td><td>SKILL.md, OpenAPI references, schema references, rulebook references, setup steps, validation checks</td><td>Teach the agent how to apply the standards and provider APIs while preserving human-review boundaries.</td></tr><tr><td>MCP connector</td><td>Model Context Protocol server/tool description exposing selected APIs, schemas, rulebooks, and validation tasks</td><td>Let the assistant call approved integration tools through a governed connector rather than ad hoc scripts.</td></tr></tbody></table>

#### 2.7.6 Ownership and brought-in components

<table data-header-hidden><thead><tr><th width="118.66668701171875"></th><th></th><th></th></tr></thead><tbody><tr><td>Category</td><td>Components</td><td>Treatment in the architecture</td></tr><tr><td>Built or configured for the Knowledge Product</td><td>Education usecase prototype; AI Integration Assistant layer; schemas; rulebooks; skill files; MCP connector; validation evidence</td><td>These are the reusable outputs that enable the usecase to be replicated.</td></tr><tr><td>Brought in as existing capabilities</td><td>EUDI Wallet for individuals and EU Business Wallet; Anthropic Claude as AI engine, standards stack, ITU cloud sandbox</td><td>These are inputs to the demonstration. The document should state which are replaceable and which boundary each replacement must satisfy.</td></tr></tbody></table>


---

# 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-02-standards-and-architecture.md?ask=<question>&goal=<user_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.