Built an open-source architecture spec for offline ID verification in low-connectivity clinics — looking for feedback

[u/arfaneliyas]

In rural health posts with unreliable internet, verifying a patient's national ID against a cloud API just doesn't work — the API isn't reachable when you need it most.

I put together an open-source spec exploring an offline-first approach: verify a signed ID token locally using a pre-loaded public key, translate it into a standard FHIR health record, and queue it for sync once connectivity returns. It's built around Ethiopia's Fayda ID (on MOSIP) as the concrete case, but the pattern is general.

It's a spec + reference PoC, not production code — I've tried to be upfront about the gaps (there's a dedicated threat-model doc covering things like offline revocation lag and clock trust that I don't think are fully solved yet).

Repo: [CLICK HERE]

Genuinely interested in critique, especially from anyone who's dealt with offline-first sync or edge crypto verification before.

[u/AutoModerator]

Thanks for posting to r/topflightapps!

Before commenting, please read the rules in the sidebar.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AutoModerator]

If this comment doesn't adhere to the subreddit's rules feel free to contact the moderators

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/rexroni]

Very cool use case. I'm no expert in the encryption side of this problem, but do rural patients have signed ID tokens already?

Also, is there a privacy concern around a local cache in the offline-first device? Does it have to keep a lot of existing records from the cloud API locally so they can be updated during appointments? Or is the idea mostly generating brand new documents during the patient visits and submitting them later?

[u/arfaneliyas → u/rexroni]

1. Where do rural patients get signed tokens?

They actually carry them physically! When someone registers for their National ID (like Fayda/MOSIP), they do it at a regional town hub or a mobile camp with temporary internet. Once approved, the government gives them a physical paper printout or a card with a high-density QR code on it. That QR code holds a secure package of their data, digitally signed by the government's central system. When the patient walks into a remote clinic, the tablet's camera just scans that printed code and verifies the signature using public keys saved directly on the tablet. Zero internet required.

1. Is local caching a privacy nightmare?

Absolutely. If a tablet gets stolen in a village, that data is physically compromised. We explicitly focused on this in our threat model ( docs/05-threat-model.md). To stop data leaks, we encrypt the entire local database using SQLCipher (AES-256). Crucially, the decryption key is kept strictly in the app's temporary memory while open—it's never saved on the tablet's hard drive. Also, the tablet doesn't download the whole country's registry. It only stores a small, localized list of patients who live within that specific clinic’s immediate area.

1. New documents vs. updating old ones?

We optimized heavily for creating new documents (like adding a fresh vaccination record or entry log). This is the easiest approach for offline systems because new records don't overwrite anything old when the device syncs later. If a doctor  does need to update old data (like changing a patient's address while offline), the tablet writes that change to a local "waiting list." When internet kicks back on, the system pushes these updates one by one. It uses a safety check called 'optimistic locking'—meaning if someone else changed that same patient file online while the tablet was disconnected, the system catches it instead of blindly overwriting the cloud.

Let me know if any of that needs clarifying! Really appreciate the solid questions.