> 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/national-learner-registry/dpi-integrations.md). # DPI Integrations X-Road for information mediation, eSignet for digital identity, and the iGrant Wallet — how the registry ecosystem connects to foundational DPI building blocks. ## Integration Architecture Overview APIs are what let the National Learner Registry ecosystem behave as a set of cooperating Building Blocks rather than a single monolithic system. Registration, the registry itself, credential issuance, digital identity, and the wallet layer are each independent components; APIs — exposed and consumed through a common integration layer — are what let them work together, and what let external systems join the ecosystem without every Building Block having to invent its own way of connecting. A useful distinction is between internal and external APIs. **Internal APIs** connect Building Blocks that sit inside the same trust boundary — for example, the registration workflow calling the National Learner Registry to check whether a Learner Profile already exists for a given national ID. **External APIs** connect the ecosystem to systems outside it: the national digital identity provider, other government registries reached through X-Road, and any third party that wants to consume or verify a credential. External APIs carry a higher bar for authentication, authorisation and monitoring, since the calling system is not already inside the trust boundary. The registry uses three complementary data-exchange patterns, depending on the need: * **Synchronous API calls** — for operations that need an immediate answer, such as requesting learner details, verifying an institution, or submitting an updated education record. * **Asynchronous messages** — for exchanges that do not need an instant response, such as larger updates, background processing, or integrations where the receiving system may not always be available. * **Events** — may be emitted without a learner record modification, but triggered via workflow processes, for example for background checks initiated by platform officials. {% hint style="info" %} Direct, point-to-point integration between systems is simple when only two systems are involved, but it does not scale: as the ecosystem grows, direct integrations create many custom connections that are difficult to secure, configure, discover, and maintain. The **Information Mediator Building Block (IMBB)** exists to avoid that. It sits as a common integration layer between Building Blocks and external systems, so that every system exposes and consumes services through one standardised path — a shared trust layer, common security controls, and one place to discover what is available — rather than a web of bespoke connections. IMBB does not own the business data that passes through it; it provides a controlled, observable path for exchanging that data. GovStack defines the capabilities expected from this Information Mediator role while remaining technology-neutral at the specification level — X-Road is the concrete implementation this PoC uses. {% endhint %} ## X-Road — Information Mediation X-Road is the technology this PoC uses to fulfil the GovStack "Information Mediator" role: a standard, secure way for systems belonging to different, independent organisations to exchange data. Rather than every system building its own separate connection to every other system, X-Road gives all participants a shared, trusted layer to connect through instead. X-Road takes care of the practical side of secure data exchange: it confirms which organisation is on each side of a request, keeps the communication channel protected, and keeps a record of what was exchanged and when. Ownership of each system and its data stays with the organisation that runs it — X-Road only provides the trusted path between them. X-Road is already used within the GovStack Assembly ecosystem that this PoC builds on, and it is an open-source, field-tested solution rather than a newly built one. Using it here means the National Learner Registry relies on a proven way of connecting to other government systems, instead of inventing a new one. In practice, this is what lets schools, the Ministry of Education, and other registries exchange learner and credential data securely, with a clear record of who received what and when. {% embed url="" %} ## eSignet — Digital Identity eSignet is the tool this PoC uses for authorisation: it confirms that the person applying for registration really is who they claim to be, before they are allowed into the Student Registration and Enrolment flow. eSignet is an open-source digital identity system, part of the MOSIP ecosystem, built to verify a person's identity once and let that verified identity be reused across services, rather than every service running its own separate check. It verifies identity against trusted sources such as a national ID, and only shares the data the applicant has consented to share. In this PoC, the applicant authenticates through eSignet before registration begins. The verified name, date of birth, and national ID it returns pre-fill the applicant's personal information and are locked from editing, since they come from a verified source rather than from the applicant. The national ID is also checked against the National Learner Registry to prevent a duplicate profile for the same person. {% embed url="" %} {% hint style="warning" %} Officer roles (School Registration Officer, MoE Registrar, and others) are **not** authenticated through eSignet — their access is governed separately through the platform's own role-based permissions. {% endhint %} ## Wallet Integration A digital wallet is where a credential lives once it leaves the issuer. Credential issuance in this PoC uses **iGrant Wallet** as the reference implementation. A wallet is not built around one type of credential — it is a general-purpose holder for credentials from any issuer willing to use the format, so the same wallet that holds a National Learner Registry credential could also hold other government-issued credentials, each from a different authority. On the education portal, the learner requests their credential and a QR code appears on screen. The QR code is not a link to a file — it is an encoded credential offer, generated at the moment the learner requests it, containing the issuer's endpoint, the credential type on offer, and a short-lived, single-use code the wallet presents back when it requests the credential; because it is single-use and time-limited, a screenshot or a reused code from an earlier session will not work a second time. Scanning the code opens a request screen naming the issuer and the credential type; the learner accepts, and the credential is retrieved and stored in the wallet. Alongside the credential, the wallet holds a key pair of its own — a **holder key** — which is what lets the learner later prove that a presented credential is genuinely theirs to present, rather than a copy taken from someone else's device. When the credential is later shown to a third party, this typically happens through an OpenID for Verifiable Presentations (OID4VP) session, opened by scanning a QR code on the verifier's side; where the credential format supports selective disclosure, the learner can choose which individual fields to reveal for that specific request, rather than sharing the whole record. {% embed url="" %} {% hint style="info" %} Everything from the wallet request screen onward — accepting the offer, storing the credential, choosing what to disclose, and presenting it to a verifier — is wallet-side functionality, outside this platform. {% endhint %} --- # 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/national-learner-registry/dpi-integrations.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.