Executive summary
Local government units across the Philippines are issuing citizen cards. Most of the visible effort goes into the card: the artwork, the printer, the launch. Most of the risk sits somewhere else entirely — in the register behind the card, in the verification path, and in the access model that decides which office can see which fields.
This piece sets out how we approach the design, based on delivering a QR-enabled citizen card program for a provincial government. The short version: build the register first, make verification a service rather than a database copy, and put a data-minimisation rule in front of every office that asks for access.
The problem
Before an identity program exists, a resident's identity is re-established from scratch at every counter. Each office keeps its own list. A resident presents whatever document they have — a barangay certificate, a utility bill, a previous permit — and the clerk makes a judgement call.
The consequences are ordinary rather than dramatic. Transactions take longer because verification is manual. Duplicate records accumulate, because there is no way to tell that the person in front of you is already on file under a slightly different spelling. Claims are difficult to audit after the fact. And when a new service launches, it starts by building its own list again.
An identity platform is worth building when several offices need to answer the same question — is this person who they say they are, and are they on our register? — and are each answering it separately.
Technical discussion
Start with the register, not the card
The register is the asset. It is the authoritative list of residents, with the fields the LGU is entitled to hold and a de-duplication rule that stops the same person being enrolled twice. Everything else — cards, apps, counter terminals — is a way of pointing at a record in the register.
De-duplication is where the engineering effort concentrates. Name matching in a Philippine context has to survive nicknames, suffixes, maternal surnames used inconsistently, and transliteration differences. Biometric capture helps, but biometrics are a matching aid, not a primary key: enrollment quality varies, and a system that hard-fails on a poor fingerprint capture will be worked around by staff within a week.
Verification as a service, not a data copy
The instinct when a second office needs access is to give them a copy of the data. Resist it. Once the register is copied, it is stale from that moment, and you now have two places to secure and two places to audit.
Instead, expose verification as a service that answers a narrow question and returns the minimum useful response. A counter asking “is this card valid and does it belong to this person” needs a confirm/deny plus perhaps a name and photo — not the full record. Designing the response per use case is the single most effective privacy control available, and it costs nothing at build time.
What goes in the QR code
Nothing personal. A QR code is not a secure container; anything encoded in it can be read by any phone. The code should carry an opaque identifier that means nothing without the verification service, so a photograph of a card yields no personal data.
This also makes revocation possible. If a credential resolves server-side, a lost card can be invalidated centrally. If the card carries the data itself, the only remedy is to reissue and hope.
Designing for the counter, not the demo
Verification happens in front of a queue. If it takes four seconds, staff will stop using it during busy periods, and the program quietly dies. We design the verification path for a sub-second response and treat that as a hard constraint, which shapes the whole architecture: narrow response payloads, indexed lookups, and no synchronous calls to anything that might be slow.
Design for the offline case too. Connectivity at a municipal counter is not guaranteed. Decide in advance what happens when the service is unreachable — queue the verification and proceed, or refuse — because staff will decide for you otherwise.
Architecture
A workable shape separates enrollment, verification and card production so that each can be secured and scaled independently:
Note what is not in the diagram: no direct database access from any consuming office. Every consumer goes through the verification service, which is what makes the access model enforceable rather than aspirational.
Recommendations
- Build the register before the card. A card issued against a register you do not trust just distributes the problem.
- Make de-duplication a design workstream, not a data-cleanup task at the end.
- Expose verification as a service with a per-use-case response. Never hand out a copy of the register.
- Put nothing personal in the QR code. Use an opaque identifier that resolves server-side, so credentials can be revoked.
- Treat sub-second verification as a requirement, because counter staff will abandon anything slower.
- Decide the offline behavior explicitly before rollout.
- Log every verification against a named account. Under RA 10173 you will need to answer who accessed what.
Conclusion
The card is the part of an identity program everyone sees, and the part that matters least. What determines whether the program is still working in three years is whether the register is trustworthy, whether verification is fast enough to use under pressure, and whether the access model was designed rather than accumulated.