Capturing passport applications and biometrics offline

The authority sends agents out to people, and the people they visit often have no connectivity. Passport applications with biometrics, the most sensitive data a government holds, therefore have to be captured on a phone in a village and uploaded later.

Requiring a connection, the usual answer, was not an option. Working offline also raises problems an online system never has: what is stored on the device, what happens if the device is lost, and how to know that the same application was not submitted twice.

We limited the offline window to one working day. Agents return their devices to the office at the end of each day, so synchronization only ever has to cover one day. Because no device comes back after weeks away, there are no merge conflicts or divergent copies to reconcile. We designed for that one-day window instead of for offline sync in general, and that is what kept the system simple enough to trust. Applications and biometrics are held in secure storage on company-issued phones that can be wiped remotely, and they upload when connectivity returns.

Company-issued phones only. Keeping biometrics on a phone is acceptable only if the phone belongs to the organization and can be wiped remotely. If agents had used their own phones, the same design would not have passed, however well the data was encrypted.

Duplicates are caught on the server. A device that has been offline cannot know what another device did. Only the server, which every device eventually talks to, can decide whether an application already exists, and it does so before the application is accepted.

Fee payment. Fees are collected through the national payment gateway, with PayPal for applicants abroad. In the public sector, regulation decides which payment provider you use.

Registry access. Calls to the national registry are secured with keys, digest authentication, single-use tokens and IP allow-listing, so a stolen key on its own opens nothing.

• Applications, photographs and biometrics captured without a connection, on devices that can be wiped remotely
• Duplicate submissions caught on the server before acceptance
• The system in production, with the app published on Google Play

We never tested what happens when a device does not come back: an agent who does not return at the end of the day, or a phone that stays out for a week. The one-day window was the right design, but a design that depends on a working habit should define what happens when the habit fails. A hard expiry on unsynced data would have cost an afternoon.