What Is the Difference Between Authentication and Identity Proofing?
Before a digital credential can be trusted, a system must answer two questions: who is this person, and are they the rightful holder of the credential?
Most credential systems claim to be "resident-centric," but few specify what that means. The phrase shows up in procurement documents, policy frameworks, and vendor marketing, as if its meaning were settled, when in practice almost any system can claim it. The word names a goal everyone shares but points to no feature you can actually check for.
That gap is worth closing, because the phrase points at something real. A digital identity system built around the needs, experiences, and rights of the people using it looks meaningfully different from one built around the administrative convenience of the agency running it. The question is how to tell them apart.
What the Phrase Is Meant to Convey
At its best, "resident-centric" describes a system where the resident, not the agency, not the vendor - is the primary design reference point. It implies that residents have meaningful control over their own data, that the system is accessible to the people it is supposed to serve, and that residents have recourse when things go wrong.
These are reasonable expectations. The difficulty is that without translating them into specific design requirements, they tend to remain aspirational. A system can be described as resident-centric while sharing more data than a given transaction requires, or while offering no meaningful alternative for residents who cannot or prefer not to participate digitally. Naming the goal is a starting point, not a guarantee.
Four Properties Worth Looking For
For individuals evaluating credential systems, four design properties are worth treating as a working definition of resident-centric, not because they are exhaustive, but because they are concrete and verifiable.
Residents control what they share. A resident-centric credential system supports selective disclosure: a resident presenting their credential for a specific purpose shares only the data that purpose requires, not everything the credential contains. Age eligibility does not require a full name. Employment status does not require an employer's name. The system's presentation layer should make this possible by design, not just by policy commitment. The principles behind this are explored in Why Privacy-Preserving Design Matters in Public Services.
Residents are not tracked across uses. A credential system where the issuer receives a notification each time a credential is presented, or where presentations to different verifiers can be correlated, creates a passive record of resident activity, whether or not that is the intent. A resident-centric system can address this architecturally: the issuer does not observe presentations, and presentations cannot be linked across contexts by third parties. This is a design choice, and it is worth specifying as such.
Residents have recourse. If a credential is incorrectly issued, a verification fails, or data is used beyond its stated purpose, there should be a clear, accessible process for the resident to seek correction or redress. This is less a technical requirement than an operational one, but it is inseparable from a system that genuinely serves residents. Digital Identity Beyond Credentials: What Governments Actually Need addresses the broader operational dimensions that determine whether a program works for residents in practice.
Residents can opt out. Where a verifiable digital credential is offered as an alternative to a physical document or traditional process, residents who choose the physical option should not be penalized or disadvantaged. Digital participation is most durable when it is a genuine choice.
The Procurement Question
An RFP that requires "resident-centric design" without specifying what that means in architectural and operational terms leaves significant room for interpretation. The phrase alone does not function as a design constraint.
A more grounded approach is to name specific properties: selective disclosure at the presentation layer, a presentation protocol that does not route information through issuer infrastructure at the point of use, a recourse process accessible to residents without legal or technical expertise, and a physical or non-digital alternative that is meaningfully equivalent. Requirements framed this way are easier to evaluate, and more likely to produce the outcomes the language intends.
For legislators, the same principle applies. Bills that specify items such as selective disclosure and opt-out protections tend to produce different procurement outcomes than bills that reference resident-centric design without elaboration. What Digital Transformation Really Means for Government offers a useful frame for why this kind of specificity tends to matter more than aspirational language alone.
A Phrase Worth Taking Seriously
None of this is an argument against resident-centric as a design goal, it is a good one. It is an argument for taking it seriously enough to define it. A system that gives residents meaningful control over their data, does not track their activity across contexts, provides accessible recourse when things go wrong, and offers a genuine opt-out is a meaningfully different system from one that only claims to be resident-focused.
That difference is worth naming clearly in policy and procurement. SpruceID builds credential systems where these properties are design requirements rather than marketing claims. If you are evaluating a credential system against this standard, get in touch to talk through what resident-centric looks like at the architecture level.
