Bridging the Digital Divide: How Delegated Agent Models Include Citizens Without Smartphones
The default architecture of digital identity is smartphone-centric. The citizen has a phone. The phone has a wallet. The wallet holds a credential. The citizen presents the credential.
This works for the 5.5 billion smartphone users in the world. It doesn’t work for the 3 billion who don’t have smartphones — or for the hundreds of millions whose smartphones are too old, too limited in storage, or too intermittently connected to run a wallet application reliably.
If digital identity infrastructure excludes citizens without smartphones, it’s not public infrastructure. It’s premium infrastructure.
The inclusion architecture
Inclusion in digital identity doesn’t mean “building a simpler app.” It means designing the system so that smartphone ownership is one access channel, not the only one.
Three architectural patterns extend digital identity to non-smartphone populations:
Delegated agents. A trusted community member — a health worker, a social worker, a village administrator — acts on behalf of a citizen using a shared or organizational device. The agent authenticates themselves, then initiates a credential interaction on behalf of the citizen (with the citizen’s consent). The credential is issued, verified, or presented through the agent’s device, but the credential belongs to the citizen.
The delegated agent model is familiar in development contexts: community health workers already administer medications, collect health data, and distribute social benefits on behalf of citizens who can’t travel to a clinic or government office. Extending this model to digital identity means the infrastructure reaches the same populations that existing social programs reach.
Offline NFC cards. A physical NFC card — issued by the government and containing a digitally signed credential — provides identity verification capability without a phone. The citizen carries the card. A verifier reads the card via NFC and checks the cryptographic signature. The card functions like a digital ID in a physical form factor.
This is architecturally identical to a smartphone-based credential: the credential is signed, verifiable, and supports selective disclosure. The difference is the carrier — a card instead of a phone. The security properties are preserved; the smartphone dependency is removed.
Multi-channel access. For credential interactions that don’t require NFC (remote verification, enrollment, status checks), the platform supports SMS and USSD channels. A citizen without a smartphone can receive notifications, confirm consent, and check credential status via basic text messaging on a feature phone.
Why delegated agents require architectural support
A delegated agent model can’t be bolted onto a smartphone-centric system as an afterthought. The architecture must support:
Agent authentication and authorization. The agent must prove they are authorized to act on behalf of citizens. This requires a separate credential for the agent — issued by their organization (the health ministry, the social services agency), attested by the trust framework, and scoped to specific actions (e.g., “can initiate health credential verification” but not “can issue credentials”).
Citizen consent capture. Even when an agent acts on the citizen’s behalf, the citizen’s consent must be captured and logged. The consent model must work in low-literacy contexts — verbal consent witnessed by the agent, captured as a timestamped event, rather than a written signature.
Audit trail separation. The system must distinguish between “agent verified citizen’s credential” and “citizen verified their own credential.” The audit trail must record who acted, on whose behalf, with what authorization, and with what consent.
Revocation of agent authority. If an agent is no longer authorized (employment termination, credential expiry), their ability to act on behalf of citizens must be revocable immediately — independent of whether the affected citizens are aware.
The KeyShare Digital ID Platform implements delegated agent support as a core capability — not a Phase 2 feature. The DIDComm Engine in the Mobile SDKs supports agent-mediated interactions. The Trust Governance Service manages agent authorization and revocation. The audit trail captures the full chain: agent identity, citizen identity, consent event, and interaction result.
The inclusion test
When evaluating a digital identity platform, ask: “Can a citizen without a smartphone receive a credential, have it verified, and access services?”
If the answer requires the citizen to acquire a smartphone — the platform fails the inclusion test. If the answer involves a delegated agent, a physical NFC card, or a multi-channel alternative that preserves the same security properties — the platform passes.
Inclusion isn’t a feature. It’s an architecture.
For the full picture of non-smartphone channels — including SMS, USSD, and physical NFC cards — see Non-Smartphone Identity.
