> 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/digital-identity-use-cases/implementation.md). # Implementation A digital national ID is as much institutional as technical. The technology is mature and openly specified; success rests on legal footing, clear rules of trust and a carefully staged rollout. ## **Foundations** * **Take stock first.** Before building, review the current position: the legal status of digital identity and electronic signatures, data-protection law, whether a public key infrastructure already exists, and how the ID system connects to other digital public infrastructure such as payments and data-sharing platforms. The gaps found here shape the rest of the plan. * **Give the digital credential legal standing.** Relying parties need certainty that the digital national ID carries the same weight as the physical card for the purposes they use it for. This may call for new regulation or an amendment to existing ID law. * **Set out the trust framework.** Define who may issue, which wallets qualify, what level of assurance each step provides, and where liability sits. The framework does not have to be complete on day one. A short, clear rulebook is enough for a pilot, and it can grow into formal agreements and certification as more participants join. ## **Build** * **Extend, don't replace.** The existing ID registry, the authority's systems and any established government portals or apps are the starting point. The credential is issued from the registry, and the wallet can live inside an app citizens already use. * **Treat the wallet as a component.** A wallet is the secure store and exchange engine; citizens meet it through an app with its own design, language support and help. Plan for both, along with the supporting pieces: the issuer system, face-matching capability, status publication and the identity provider. * **Stay on open standards.** Using the standards listed earlier, and open-source components where they fit, keeps the system interoperable, reduces dependence on any one supplier and keeps ownership with the state. ## **Roll out** * **Start with a few services that matter.** Launch with a small number of high-demand government services that accept the digital ID for sign-in. Citizens adopt a credential when it saves them time on something they already need to do. * **Bring relying parties in early.** Engage the ministries and agencies whose portals will accept the credential, and later banks, telecom operators and others, while the design is still open. Their requirements should shape which attributes the credential carries. * **Build interoperability in layers.** Agree first on formats and protocols, so systems can exchange credentials; then on trust, so participants recognise each other's keys and lists; and finally on legal recognition, so a credential is accepted across sectors and, in time, across borders. * **Learn and widen.** Use the pilot to test the journey with real citizens, fix friction, and then extend to more services and more credential types. ## **Inclusion** * **Keep a route that doesn't need a smartphone.** The OTP sign-in path lets citizens without a smartphone, or who have not yet claimed their digital ID, use the same services. * **Offer assisted access.** Service counters and assisted access points help citizens complete the face match, set up a wallet or sign in when they need support. * **Design for everyone.** Local languages, accessible interfaces and clear explanations of what is being shared make the difference between availability and real uptake. * **Add, don't take away.** The digital credential is an additional channel. The physical ID and existing ways of proving identity stay in place. --- # 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/digital-identity-use-cases/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.