Verified-Once Public Services: Reusable Proof Without Surveillance IDs

Reusable proof is the missing trust layer

Public services do not fail only because rules are complex. They fail because evidence is fragmented. A person may be eligible, but the system asks them to prove the same fact in the least efficient way possible: fetch a paper notice, scan a license, upload a pay stub, mail a signed consent, call a school, request a transcript, ask another agency for a letter, and repeat the process when the next program asks.

That is why verified-once service belongs next to Law as an API, the Time Ledger, and Right to Send Your Agent. Machine-readable rules tell people what proof is needed. The Time Ledger counts the hours lost when proof is repeated. Citizen agents can help move evidence through a process. Verified-once service supplies the trust layer: the reusable, consented proof that a fact is true.

The principle is simple. If the government or another trusted issuer has already verified a fact, a person should be able to reuse that verification with less friction and less exposure. The answer is not a giant identity database. The answer is a narrow proof system that asks, "What is the minimum fact this service needs, and can the person authorize that fact to be checked without moving the whole file?"

Surveillance safeguards are mandatory

The strongest fear is the obvious one. A reusable proof layer can become a national ID system in practice even if nobody calls it that. If every service demands the same credential, every transaction leaves the same identifier, and every agency can query a shared profile, the paperwork problem has been solved by creating a tracking problem.

The platform should reject that design up front. Verified-once service should follow six rules:

1. No mandatory single wallet. People should be able to use account-based, wallet-based, paper, in-person, navigator-assisted, and agency-mediated paths.
2. No universal tracking identifier. The system should use pairwise, purpose-bound, or transaction-specific identifiers where possible, not one number carried everywhere.
3. Selective disclosure first. Prove the claim, not the whole document.
4. User request or clear legal authority. Evidence exchange should happen because the person requested it, or because a statute clearly authorizes it with notice and safeguards.
5. Receipts and logs. People should see what was shared and by whom.
6. Paper and human fallback. A digital proof route cannot become the only path to public service.

Those constraints are not decoration. They are what make the issue a privacy plank rather than a service-delivery convenience.

What people should be able to prove

The first verified facts should be common, high-burden, and easy to scope:

1. identity proofing for high-risk accounts;
2. address or residence;
3. age threshold;
4. income band or tax filing status;
5. disability determination;
6. veteran status;
7. student enrollment or completion;
8. professional license or permit status;
9. business registration and beneficial ownership where lawful;
10. work authorization;
11. health coverage status;
12. program enrollment or prior eligibility determination.

Each proof should be bounded. A food benefit renewal may need household and income facts. A local discount program may need residence and age. A licensing portal may need proof that a training credential is current. None of those should require opening a full case file when a narrow attestation would do.

The technical model should be plural

There is no single right architecture for every proof. Some cases need a shared account, some need a credential in a wallet, some need an agency-to-agency attestation, some need a paper document, and some need a human navigator because the person's circumstances are complex.

NIST's digital identity guidelines give agencies a risk-based language for identity proofing, authentication, and federation. NIST's mobile driver's license work shows how a government credential can be cryptographically verifiable and support selective disclosure. W3C's Verifiable Credentials Data Model describes an issuer-holder-verifier ecosystem for tamper-evident credentials on the web. Login.gov shows how shared accounts and identity verification can reduce duplicate account creation, while its own history also shows why implementation needs oversight, privacy controls, and multiple verification paths.

The policy should therefore set outcomes, not mandate one product. A compliant proof rail should answer these questions:

1. Who issued the proof?
2. What fact is being asserted?
3. What service is asking for it?
4. What is the legal basis and purpose?
5. What data is disclosed?
6. How long does access last?
7. Can the person revoke future use?
8. How is the proof corrected if wrong?
9. What happens if the person cannot use the digital path?

Consent requires a continuing workflow

Consent should be specific enough to be useful. A person should not face a vague screen that says "share my information" with no explanation of which information, from which source, for which transaction. Consent should produce a receipt.

A strong receipt would say:

1. "The housing agency requested proof of current SNAP enrollment."
2. "The proof came from the state benefits agency."
3. "No income documents, medical records, or full case file were shared."
4. "The proof can be used only for this application."
5. "You can view this transaction and revoke future reuse here."
6. "If the proof is wrong, start correction here."

That is the user-facing version of data minimization. It is also the fraud-control version: clear scopes, receipts, and logs make forged consent and inappropriate access easier to detect.

Evidence exchange should reduce total burden

The public-sector version of verified-once service is evidence exchange. A service asks for a fact. The person authorizes the request. The issuing agency confirms the narrow fact or sends a credential. The receiving agency records the result. The person sees the receipt.

The European Union's Once-Only Technical System is a useful comparator, not a template to copy wholesale. It lets public authorities exchange official documents and data at the request of citizens and businesses for cross-border procedures. The United States has a different federal structure, different privacy law, and different trust politics. The lesson is not that the U.S. should import the EU system. The lesson is that "prove it once" can be made into operational infrastructure instead of a slogan.

Guardrails against exclusion

Identity systems fail people at the margins first. People may lack a current driver's license, a stable address, a Social Security number match, a credit history, a smartphone, a camera, reliable broadband, English fluency, transportation, or the ability to pass automated face matching. Some people have safety reasons to avoid exposing address or identity data. Others have records that are true but messy: changed names, guardianship, foster care, immigration transitions, domestic violence protection, homelessness, disability, or institutional records split across agencies.

Verified-once service must not treat those cases as edge clutter. They are the integrity test. The policy should require:

1. in-person and assisted verification options;
2. paper alternatives;
3. language access and disability access;
4. error correction before denial;
5. no automated final denial based only on a failed identity or credential match;
6. equity audits by channel, geography, disability status, language, age, and income where lawful and privacy-safe;
7. special privacy routes for survivors, minors, protected addresses, and sensitive health or family records.

The right conclusion is not to abandon reusable proof. It is to build it with enough humility that the person who cannot use the clean digital path still gets served.

Start with existing rails

The first phase should build from programs that already have legal or technical footing:

1. Login.gov shared authentication and identity verification for federal, state, local, and territorial government services;
2. CASES Act access and consent forms for Privacy Act records;
3. mobile driver's license and verifiable credential pilots;
4. high-impact public services under OMB customer-experience policy;
5. benefits renewal and recertification where eligibility facts already sit in government systems;
6. tax, student aid, veterans, disability, passport, licensing, and business-registration processes with repeated evidence demands.

This lets the country learn in high-burden areas without pretending every proof is ready on day one.

What the first year should require

The first year should produce standards and working pilots:

1. OMB, GSA, NIST, and agency partners should define a verified-once public-service standard: consent receipt, proof scope, revocation, correction, logging, retention, paper fallback, and appeal rights.
2. High Impact Service Providers should identify their ten most duplicated evidence requests and publish a plan to reduce them.
3. Login.gov and partner agencies should publish conformance guidance for reusable identity and attribute proof without forcing a single identity method.
4. Agencies implementing CASES Act digital consent should expose lessons learned and reusable components.
5. NIST should maintain public test profiles for mDLs, verifiable credentials, selective disclosure, and remote presentation in public-service use cases.
6. Inspectors general and GAO should audit whether pilots reduce burden, protect privacy, and preserve access for people who cannot use the digital path.

Verified-once service is a practical doctrine for the AI era. If citizens are going to send agents, if law is going to become testable, and if government is going to count hours returned, people need reusable proof they control.