> For the complete documentation index, see [llms.txt](https://docs.mosip.io/1.2.0/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mosip.io/1.2.0/setup/cookbook/references.md). # References ## Critical Success Factors and Risks\*\* ### Success factors * Country infrastructure (on-prem or cloud) is available at the earliest possible time, with the access and security approvals MOSIP needs to deploy. * Country project team --- program, technical, field is identified, trained and available full time during the registration window. * Non-biometric components of the registration kit (laptop, photo booth, printer/scanner, monitor, helpdesk and admin terminals) are procured and tested before training begins. * Biometric devices arrive on time and pass acceptance testing at first delivery. * ID schema and master data are signed off at the beginning of the pilot, anything later cascades into the registration window. * Participant pool reflects the population mix, including children, minors, senior citizens and persons with disabilities. * Functional training is paired with real registrations; no operator goes to the field untested. Some countries have even conducted examinations and grading to operators. ### Top risks and mitigations | Risk | Impact | Mitigation | | ------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Biometric devices delayed at customs | Compresses or cuts the field window. | Country pre-clears customs; MOSIP ships in two waves so a partial shipment can start training. | | On-prem environment not ready | Deployment slips, downstream training and customisation cascade. | Have a public cloud fallback environment pre-approved as a contingency (depends on country's sovereign principles). | | Operator attrition during the pilot | Loss of trained operators forces re-training mid-flight. | Train at least 1.5× the operators required and rotate them through Centers. | | ID schema changes late into the pilot preparation | Triggers re-customisation and re-test of the registration UI. | Freeze the schema by end of Week 3; treat post-freeze changes as scope changes needing committee approval. | | Connectivity outage at a Center | Online registration grinds to a halt. | Offline mode is enabled, exercised during training, and used as the default fall-back. | | Low resident turnout | Cannot reach 3,000 registrations in the window. | Communications focal point runs structured outreach via campaigns and partner channels; Centers open extended hours in the last week and may be use weekends. | ## Appendix A **Registration Center Setup Checklist** Print this page and do an audit with a supervisor before the first registration. Tick everything before opening to residents. | Area | Checks | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Power and connectivity | Power outlets sufficient for laptop, monitor, printer/scanner, lights and devices. Surge protection in place. Wired or stable Wi-Fi tested at the kit. Offline-mode fallback verified end to end. | | Registration kit | Laptop (specs per Section 5.2) up to date, antivirus current. Citizen-facing monitor connected. Fingerprint slap scanner, dual iris scanner and face camera tested with sample captures. | | Documents and printers | Printer/scanner installed. A4 paper, ink/toner stocked. Document scanner tested with a sample identity document. | | Photo booth | Backdrop and lights set up; framing tested with a person of average height. Lighting uniform; no shadow on the face. A chair placed at a distance from the camera to get a good photograph. | | Helpdesk and admin | Supervisor terminal logged in with helpdesk role. Admin terminal accessible only by the country admin. Incident log template available. | | Resident experience | Signage and queueing arranged with accessibility in mind. Seating available, including for senior citizens and residents with disabilities. Drinking water and rest areas signposted. | | Compliance | Consent forms printed in the language(s) used by participants. Data-handling poster displayed. Incident contact details visible at every kit. Good, average and poor quality biometrics printed and pasted in various locations in the center with copies circulated to supervisor and operators. | ## Appendix B **Day-of-Pilot Operator Run Sheet** A condensed run sheet for an operator on a registration day. Localize it for your Center. | Phase | What the operator does | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Start of day | Power on the kit. Verify the operator login and date/time. Run a self-test capture on the fingerprint, iris and face devices. Print a calibration page from the printer. | | Pre-registration check | Look up the resident's pre-registration appointment. Confirm identity documents match. Confirm consent. | | Demographic capture | Capture demographics in the country language, in the agreed schema. Re-read each entry to the resident before saving. | | Biometric capture | Capture fingerprints (slap), iris (dual) and face. Repeat captures whose quality score is below threshold. For exceptions, mark the missing-biometrics and call the supervisor. | | Document scan | Scan the supporting document at 300 dpi. Confirm legibility before saving. | | Submit packet | Submit the packet. In offline mode, queue it for sync and note the packet ID on the manual log. | | Authentication exercise | If the resident is part of the authentication sample, walk them through eSignet OTP or biometric flow at the mock RP portal. Demonstrate INJI Wallet credential download if requested. | | End of day | Sync any offline packets. Power down devices. Lock kit. Hand the daily metrics sheet to the supervisor. | ## Appendix C **Experiencing Security and Privacy during the Pilot** The MOSIP pilot is deliberately designed so that security and privacy are not theoretical. Every step of the pilot --- from configuring network rules on Day 1 to watching the consent screen during authentication --- is an opportunity for the country team to build the operational instincts needed to govern a national identity system responsibly at scale. ### What the Team Experiences | Layer | What you experience / observe | Security / privacy principle at work | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Biometric capture** | Biometric data leaves the device encrypted. The operator never sees raw fingerprint or iris data on screen --- only a quality score. | Data-at-capture encryption via SBI device; hardware-bound keys in TPM on the registration laptop. | | **Registration packet** | Every packet uploaded from the Registration Client is encrypted before it travels over the network. Even if intercepted, it is unreadable. | AES-256 encryption; hybrid key wrapping with RSA. Packet is signed with the machine's TPM key, binding it to the physical hardware. | | **MOSIP core platform** | Observe in the Admin Console that each resident's UIN is never stored in plain text. Identity and biometric data are stored in separate encrypted stores. | Zero-Knowledge encryption on biometric templates; UIN hashing and encryption; AES keys per data category stored in HSM / SoftHSM. | | **Deduplication (ABIS)** | Watch biometric deduplication run without any human operator seeing the templates being compared. Results return as match / no-match only. | Biometric templates are shared with ABIS in encrypted form. ABIS returns a score --- never the raw template back to MOSIP. | | **eSignet authentication** | Authenticate using OTP and fingerprint. Observe that the relying party (mock health portal) receives only a pseudonymous token --- not the resident's real ID number. | Partner Specific User Token (PSUT) --- each service gets a different identifier for the same resident. Cross-service profiling is cryptographically prevented. | | **INJI Wallet** | Download a credential to a phone. The credential is a signed Verifiable Credential that can be verified offline --- no call back to MOSIP needed. | W3C Verifiable Credential with cryptographic proof. Credential is bound to the wallet's hardware key (Android Keystore / iOS Secure Enclave). | | **Consent** | See the consent screen appear before any data is shared with a relying party. The resident explicitly approves what is shared. | Consent is recorded as an artifact with a unique ID. No data leaves MOSIP without a valid consent record. | ### Key privacy behaviors observed during Registration During the pilot, specifically observe and discuss the following with your team: * The operator never sees the resident's biometric data in raw form --- only a quality indicator (green / amber / red). This is enforced by the SBI device driver, not just policy. * The citizen-facing screen shows the resident their own data before submission, giving them the opportunity to correct errors --- a built-in data accuracy and consent mechanism. * Acknowledgement slips printed for residents contain only the Application ID, not the resident's full biometric or demographic record. * The deduplication process (ABIS) never returns the matching resident's data to an operator --- only a match / no-match flag routes to manual adjudication. * eSignet consent screen lists exactly which data fields a relying party is requesting. The resident can see and refuse before any data is shared. * The INJI Wallet credential shows the resident's data but the verifier's QR scan returns only a cryptographic validity result --- the verifier cannot harvest and store the resident's data from the scan. ### Questions to guide your team's security discussion | For the Technical Team | For the Policy Team | | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | | What happens to a registration packet if the network drops mid-upload? Is it lost, or stored securely and retried? | Which government authority will be the data controller for resident biometrics at national scale? | | Who in MOSIP has the ability to decrypt a stored biometric? What prevents misuse? | What data retention policy will apply to packets and logs once ID is generated? | | How would we detect if a rogue operator was registering fictitious residents? | Under what legal authority can a third-party service request a resident's eSignet authentication? | | What is the process for rotating the signing keys after the pilot? | How will residents exercise their right to correction or deletion under the country's data protection law? | | How do we ensure the SoftHSM seed material is protected, and what replaces it in production? | What audit trail must be maintained for each resident's data access events? | --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.mosip.io/1.2.0/setup/cookbook/references.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.