Standards are the infrastructure upon which all interoperability is constructed. A digital identity system that does not implement internationally recognised, open standards becomes a technical silo: capable of data exchange only within its own ecosystem, and unable to participate in cross-institutional, cross-border, or cross-sector identity verification without bespoke, bilateral integration arrangements. The DIAL Guidebook observes that without standards, “the identity solution basically becomes a silo, only able to exchange information within its own walled-off garden. This leads to vendor lock-in, meaning the Holder has limited control over how this identity information can be used” (Digital Impact Alliance, 2023, §3.6.1). For governments pursuing AfCFTA integration and regional DPI harmonisation, non-compliance with this criterion is not a technical gap but a strategic failure.

1. Which internationally recognised standards does the identity system implement for credential format, biometric encoding, authentication protocol, and data exchange? (Relevant standards include, inter alia: W3C Verifiable Credentials Data Model v1.1; ISO/IEC 18013-5 for mobile driving licences and identity credentials; ISO/IEC 19794 for biometric data interchange; FIDO2/WebAuthn for authentication; and OpenID Connect 4 Verifiable Presentations for credential presentation.)
2. How do the implemented standards support addressability — the ability to uniquely locate and reference a presented identity claim from any participating reliant party?
3. How do the implemented standards support verifiability — the ability to cryptographically confirm that a presented claim has not been tampered with since issuance, and that it was issued by a legitimately trusted authority?
4. Has the jurisdiction conducted a formal standards gap analysis against the above-referenced international benchmarks, and has this analysis been documented and published?
5. Are standards requirements formally embedded in procurement specifications, contractual performance obligations with vendors, and system acceptance criteria?
6. What process exists for evaluating and adopting new or revised standards as the global identity technology landscape evolves?

The DIAL Guidebook defines the identity lifecycle as comprising five stages: identity proofing; issuance; authentication; authorisation; and identity management (including recovery) (Digital Impact Alliance, 2023, Glossary). This criterion extends standards compliance beyond the credential format layer — which may achieve headline compliance with W3C or ISO standards — to require that every component across all five stages implements recognised standards. A system that issues W3C Verifiable Credentials but performs biometric enrolment using proprietary encoding, authenticates using a proprietary protocol, and manages recovery through an undocumented vendor-specific process, achieves only partial lifecycle interoperability. Full lifecycle standards compliance is the condition under which maximum interoperability is achievable.

1. Has a complete lifecycle architecture document been produced that maps each system component — proofing, issuance, authentication, authorisation, recovery — to a specific recognised standard?
2. Are there lifecycle stages where proprietary or non-standard components are deployed? If so, what documented justification exists, and what is the remediation plan?
3. How does the system facilitate data portability across the lifecycle — specifically, can a Holder extract their complete identity data in a standards-based format from any point in the lifecycle?
4. Are lifecycle components independently interchangeable — that is, can one component (e.g., the authentication layer) be replaced by an alternative compliant component without disrupting the remainder of the system?

Application Programming Interfaces (APIs) are the technical mechanism through which identity systems integrate with external services: government ministries, financial institutions, healthcare providers, border control agencies, and cross-border reliant parties. The MUST designation establishes open APIs as a non-negotiable baseline. The DIAL Guidebook specifies that “API definitions should be published publicly, meaning that anyone who wants to read the API documentation can without restriction” (Digital Impact Alliance, 2023, §3.6.3), establishing a principle of documentation transparency that eliminates the practical lock-in that arises when API access is controlled by the vendor through registration requirements, commercial licensing, or technical obscurity. With open APIs, “those deploying the system can expand and/or update the use of the identity system as the needs evolve, as well as add/replace components of the identity system that may not be provided by the original vendor” (Digital Impact Alliance, 2023, §3.6.3).

1. Are all API specifications for the national identity system publicly documented and freely accessible without registration, commercial licensing, or vendor approval?
2. Does a developer sandbox and portal exist, enabling potential reliant parties to test integrations before operational deployment?
3. What restrictions, if any, are placed on API access? Are such restrictions legally justified, proportionate to stated security objectives, and individually documented?
4. Do the available APIs cover all stages of the identity lifecycle for which reliant party integration is required?
5. What security controls govern API access — specifically, how are reliant parties authenticated, how are API requests authorised, and how are rate limits and abuse controls implemented?
6. How are API versioning, backward compatibility, and deprecation timelines managed to protect reliant party integrations from disruption?
7. What onboarding process exists for reliant parties seeking API access, and does this process introduce barriers inconsistent with the open API principle?

Data portability APIs serve two legally and operationally distinct purposes: they protect governments’ right to migrate between identity system vendors without data loss, and they protect citizens’ rights to access, extract, and — where legally applicable — delete their identity data. Both purposes are constitutive of a functioning DPI governance regime. The DIAL Guidebook observes that without portability APIs, “there is vendor lock-in which limits the ability of the Holder to exercise control over the data” (Digital Impact Alliance, 2023, §3.6.4). For national governments, this translates to a loss of sovereign control over foundational national infrastructure: a state locked into a vendor ecosystem due to absent portability mechanisms cannot exercise meaningful procurement authority, cannot respond to vendor service failure, and cannot migrate to superior technological solutions as they become available.

1. Do portability APIs exist for all system components, including biometric enrolment data, credential registries, consent records, event logs, and audit trails?
2. In what format is extracted data structured? Is this format based on a recognised international standard — specifically, one that can be ingested by alternative identity system platforms?
3. Has the government conducted a controlled data migration exercise to validate that portability APIs function as specified in an operationally realistic scenario?
4. Are portability rights, including the data format specifications and associated Service Level Obligations, contractually guaranteed in all vendor agreements?
5. What authentication and authorisation mechanisms govern portability API access, ensuring that mass data extraction is prevented except by authorised parties?
6. Has independent legal counsel confirmed that portability API provisions in current vendor contracts are enforceable under applicable law?

This criterion identifies a sophisticated and frequently overlooked form of vendor lock-in: the use of intellectual property instruments — patents, trade secrets, or contractual non-compete clauses — to prevent competing vendors or government technical teams from implementing systems that share the same API interface specification. Such legal encumbrances may not be visible in the technical specification of the API itself, but may be embedded in software licencing terms, vendor contracts, or proprietary technology disclosures. Their effect is to create a monopoly over the integration ecosystem even when the technical interface is nominally published. The DIAL Guidebook specifies that “the vendor needs to allow for reuse of their published API interfaces. In other words, they must not pursue actions, including legal, to prevent other organisations/developers from creating services that utilise the same API interfaces” (Digital Impact Alliance, 2023, §3.6.5). This criterion requires legal scrutiny as a complement to technical review.

1. Have vendor contracts been reviewed by legal counsel specifically for provisions that restrict the government’s ability to commission alternative implementations of the API interface?
2. Does the vendor assert intellectual property rights over the API interface specification — as distinct from the implementation — that would prevent third-party reimplementation?
3. Are API interface specifications published under an open licence (e.g., Creative Commons, Apache 2.0) that explicitly permits reimplementation by third parties?
4. Does the government maintain a registry of all proprietary claims made by identity system vendors over interface specifications, protocols, and data schemas?

Machine-readable data export is the operational realisation of the data portability principle. The DIAL Guidebook specifies that exports should follow “recognised standards for syntax and semantics” and should “endeavour to support structuring the identity data such that it can be imported into other solutions, where possible” (Digital Impact Alliance, 2023, §3.6.6). This requirement has direct implications for national data sovereignty: a government that cannot extract its citizens’ identity data in a standards-based, system-agnostic format is functionally dependent on its vendor for the continued operation of foundational national infrastructure. Where this dependency exists, it translates into leverage that vendors may exploit — consciously or otherwise — during contract renegotiations, service pricing discussions, or dispute resolution proceedings.

1. What data export formats are supported? Are these formats based on recognised open standards — specifically, formats that can be ingested by at least two alternative, commercially available identity system platforms?
2. Does the data export cover the complete identity data record — all attributes, associated metadata, consent records, and audit history — or only a subset?
3. Can data exports function as operational backups — that is, can the complete identity system be restored from an export in a documented, tested recovery procedure?
4. Is there any functional loss when data is exported and imported into an alternative platform? If so, what functionality is lost, and what is the remediation plan?
5. What security controls govern the export function, ensuring that bulk identity data extraction occurs only under authorised conditions?

Trust and governance frameworks are the non-technical dimension of interoperability that govern the rules of engagement between participants in an identity ecosystem. The DIAL Guidebook observes that “identity cannot be solved with technology-only solutions, and trust/governance frameworks pick up where the technology leaves off” (Digital Impact Alliance, 2023, §3.6.7). For the six cohort countries, the relevant frameworks include — at the regional level — the EAC Digital Integration Programme, the SADC Protocol on Trade in Services, the ECOWAS biometric identity framework, and the IGAD Regional Migration Policy Framework; and — at the continental level — the African Union Data Policy Framework (African Union, 2022) and the AfCFTA Protocol on Digital Trade. A deployed identity system that cannot technically participate in these frameworks — because it lacks the governance metadata, trust registry integration capability, or cryptographic interoperability required — is effectively excluded from the regional DPI ecosystem regardless of its domestic functionality.

1. Is the national identity system designed — from an architectural standpoint — to participate in external trust frameworks, or is it structurally closed to such participation?
2. What governance model is envisaged for any trust framework in which the jurisdiction intends to participate — bilateral, multilateral, regional body-anchored, or industry-led?
3. How are access rights codified within the trust framework? Specifically: who may issue credentials recognised by the framework; who may act as a reliant party; and under what conditions is cross-border credential presentation permitted?
4. What consensus mechanism governs amendments to trust framework rules, and how is the jurisdiction’s institutional voice represented in framework governance?
5. What dispute resolution mechanisms exist when trust framework rules are violated — by an issuer issuing fraudulent credentials, by a reliant party exceeding its authorised data use, or by the trust framework operator itself?
6. How does the jurisdiction’s existing legal framework — encompassing data protection legislation, electronic transactions law, and identity law — interact with trust framework obligations, and where are the principal legal tensions?

The DIAL Guidebook illustrates the purpose of this criterion through the example of a medical trust framework: a pharmacy must be able to verify that a credential-issuing physician is licensed, and a patient must be able to verify that the pharmacy is legitimate — both without requiring direct contact with the relevant licensing authority for each individual transaction (Digital Impact Alliance, 2023, §3.6.9). Equivalent mechanisms are required at national level: a government service must be able to confirm that a presented credential was issued by an authorised, registered issuer without creating a “phone home” request that reveals to the issuer who is verifying which credential, at what time, and for what purpose. Absent such automated validation mechanisms, trust framework participation degenerates into a series of manual, bilateral verification calls that do not scale to population-level digital service delivery.

1. Does the trust framework include a cryptographically verifiable issuer registry that enables reliant parties to confirm issuer legitimacy without contacting the issuer at transaction time?
2. Does the trust framework include a mechanism for holders to validate the legitimacy of reliant parties making credential presentation requests?
3. Are validation mechanisms implemented within the identity system software itself, enabling automated validation without manual look-up processes?
4. How are trust framework validation mechanisms operated in offline scenarios — specifically, in geographic areas with limited or intermittent network connectivity?

Open-source software adoption in national identity systems serves multiple simultaneous strategic objectives: reducing vendor lock-in risk by enabling the government to operate, maintain, and modify the system with any qualified technical team; enabling peer review of the codebase by a broader technical community; facilitating knowledge transfer to domestic technical talent; and permitting adaptation and extension of the system without proprietary licensing constraints. The DIAL Guidebook recognises that open-source adoption may not always be fully achievable — “systems may be a collection of both open- and closed-source software” — but establishes that “open-source software provides several advantages, including limiting vendor lock-in and the possibility of a wider code review” (Digital Impact Alliance, 2023, §3.6.2). For the cohort countries, the MOSIP (Modular Open Source Identity Platform) adoption by Malawi and Ethiopia represents a concrete application of this principle.

1. What proportion, by functional component, of the current identity system is implemented using open-source software? Is this proportion formally documented?
2. What identity functions are handled by open-source components, and which are handled by proprietary software?
3. Are open-source licences used by the system (e.g., MIT, Apache 2.0, MPL) compatible with government use, modification, and procurement of maintenance services from alternative vendors?
4. Does the jurisdiction have resident technical capacity — within government or in the domestic private sector — sufficient to maintain and modify open-source components without dependence on the original implementing vendor?
5. Has the government contributed to the open-source communities from whose work it benefits — through code contributions, bug reports, or financial support — consistent with sustainable open-source governance principles?

Vendor lock-in in deployed identity systems is a multi-layered risk, operating simultaneously at the technical, contractual, financial, and capability levels. At the technical level, proprietary data formats, closed APIs, and undocumented system architecture prevent migration. At the contractual level, long-term exclusive agreements, termination penalties, and inadequate source code escrow provisions constrain sovereign decision-making. At the financial level, high switching costs create de facto monopoly leverage for incumbent vendors during contract renewals. At the capability level, insufficient domestic technical expertise creates dependency even when technical and contractual barriers have been formally addressed. The DIAL Guidebook prescribes a comprehensive response: open-source technologies, local capacity building, and careful legal agreement design must all be pursued in parallel (Digital Impact Alliance, 2023, §3.6.8).

1. What contractual mechanisms exist to protect the government’s right to migrate to an alternative vendor? Specifically: are source code escrow arrangements in place; is the escrow independently verified; and under what conditions is escrow release triggered?
2. Has the jurisdiction invested in domestic technical capacity — within government or the domestic private sector — sufficient to operate and modify the identity system independently of the original implementing vendor?
3. What is the estimated total cost of switching to an alternative vendor for each major system component? Has this been formally quantified as part of a vendor independence risk assessment?
4. Are open-source alternatives to current proprietary components formally documented and evaluated in the jurisdiction’s technology roadmap?
5. Are legal agreements with identity system vendors reviewed by counsel with specific expertise in technology procurement and DPI governance, rather than general commercial law?