Proving Who You Are Without a National ID: A FIVS Proof of Concept

I ran into a question a while back that I couldn't put down: how do you verify someone's identity across the whole country without building a national ID?

Those two goals hate each other. The US doesn't have a national ID for legal, constitutional, and political reasons, and good luck changing that. But we still have real identity fraud and fifty states handing out credentials that barely talk to each other. So I wanted to know if you could satisfy both constraints at once.

I sketched a system and called it FIVS, the Federated Identity Verification System. Fair warning, this is a proof of concept on paper. I haven't built the whole thing. What surprised me is how much of it already exists.

The idea: a trust framework, not a database#

A national ID means Washington makes the ID, stores the data, and decides who gets to look at it. FIVS flips all three:

• States issue the credential and keep the records, same as today.

• The federal government runs a certificate authority that says which state issuers are legit. That's the whole job.

• Verifiers (TSA, a bank, a bar) check a cryptographic signature. Nobody phones home to DC.

Best analogy I've got: the Federal Reserve certifies that banks are real banks. It doesn't watch what you buy with your debit card. Same shape here. Vouch for the issuer, then stay out of the transactions.

Architecture#

flowchart TD
    R["Federal Root CA<br/>(air-gapped HSM, ceremony-signed)"]
    A["State A intermediate CA"]
    B["State B intermediate CA"]
    C["State C intermediate CA"]
    W["Citizen wallet<br/>(Secure Enclave / StrongBox)"]
    V["Verifier<br/>(TSA, bank, bar, employer)"]

    R --> A
    R --> B
    R --> C
    A -->|issues credential| W
    W -->|selective disclosure| V
    V -.->|checks signature chain offline| R

The chain goes federal root, state intermediate, credential on your phone. A verifier needs the root cert and whatever you present. No live lookup against the DMV or the feds. That one property is what keeps this from becoming a giant surveillance honeypot, so I'd defend it hard.

What each piece does#

Federal root CA. Run by NIST or an arm's-length chartered nonprofit. It signs one intermediate cert per participating state and logs every issuance to Certificate Transparency. It holds public keys and cert metadata. Zero citizen data.

State registries. To join, a state passes a NIST SP 800-63-3 IAL2 audit, signs credentials with HSM-backed keys (FIPS 140-3), runs a revocation endpoint, and keeps its own append-only audit log. Joining is voluntary, with federal money as the carrot. That's how REAL ID worked.

Wallets. Not a government app. It's a spec that Apple, Google, and Samsung wallets implement, with keys locked in the device's secure hardware and an on-device log of what you shared and with whom.

Verifier SDK. Open source, so a bar and a bank integrate the same way. The verifier says what it wants and why, and you approve it on your phone.

from fivs_verifier import VerificationSession, ClaimRequest

session = VerificationSession(trust_root_cert=FEDERAL_ROOT_CERT)

# Ask only for what you need
request = ClaimRequest(
    required_claims=["over_21"],
    optional_claims=[],
    purpose="Age check for alcohol purchase",
    retention_policy="no_retain",
)

result = session.verify(qr_payload, request)
print(result.claims["over_21"])  # True. Nothing else is ever revealed.

Yes, I made up that package name. The point is the shape of the API: the request is explicit, minimal, and visible to the user.

Two credential types#

Your plastic card keeps working. FIVS adds a layer. It doesn't rip anything out.

The privacy part#

This is the part I actually care about, so it gets the most words.

Selective disclosure#

A normal license shows your name, address, birthday, and ID number to anyone who glances at it. With SD-JWT, each claim gets hashed inside the signed credential, and you reveal only the ones a verifier asks for.

{
  "iss": "https://dps.example-state.gov",
  "iat": 1749168000,
  "sub": "<blinded_identifier>",
  "_sd": [
    "hash_of_full_name",
    "hash_of_dob",
    "hash_of_address",
    "hash_of_over_21",
    "hash_of_us_resident"
  ]
}

Your wallet hands over the over_21 disclosure and nothing else. The verifier recomputes the hash, confirms it lives inside a validly signed credential, and gets a yes. The bar never learns where you live.

Unlinkable presentations#

Selective disclosure has a leak, though. If the same signature and identifier show up at two verifiers, they can compare notes and figure out it's you. BBS+ signatures fix that by letting the holder generate a fresh, randomized proof every time. Two businesses comparing logs can't tell it was the same person.

Pseudonyms handle the identifier side. The wallet derives one per verifier:

Here $v$ is the verifier's identity and $k_{\text{device}}$ never leaves secure hardware. Different verifier, different value, nothing to join on.

What the state sees#

When you get issued a credential, the state knows. When you show it somewhere, the state gets no signal at all. It knows you have a license. It has no idea where you used it. Honestly, that's more privacy than the plastic card gives you today.

The standards stack#

I didn't invent any of this. I mostly just assembled it.

How you actually get one#

I mapped out ten user flows, 105 steps total, and built an interactive version in React because apparently I can't stop. The big one is first-time issuance.

sequenceDiagram
    actor C as Citizen
    participant W as Wallet
    participant S as State issuer
    C->>W: Start enrollment, pick state
    W->>S: OpenID4VCI request
    S-->>W: Challenge, prompts liveness check
    C->>W: Selfie (liveness per ISO 30107-3)
    W->>S: Selfie plus device attestation
    S->>S: Match against enrollment photo, delete biometric template
    S-->>W: Signed credential
    W->>W: Store in Secure Enclave / StrongBox, require Face ID or fingerprint

The state compares your selfie to the photo it already has from your last DMV visit, then deletes the biometric template after the match. The credential lands in secure hardware and gets bound to that device.

The other nine flows:

Rollout#

The plan runs in three phases:

• Years 1 to 2, ratification. Congress passes enabling legislation, NIST gets chartered to run the root CA, and DHS, SSA, and the state DMVs form an interagency group. Federal funding in the REAL ID range ($500M to $1B) goes to state upgrades, and a reference implementation ships open source.

• Years 2 to 4, state onboarding. States apply, pass the NIST audit, and get intermediate certs. Citizens opt in to a digital credential alongside their physical card.

• Years 3 to 5, verifier ecosystem. Federal agencies go first (SSA, VA, IRS, TSA), then banking through KYC rulemaking, then state-to-state uses like licensing reciprocity.

The objections I'd expect#

Is it feasible today?#

On the tech side, mostly yes. As of early 2026, 21 states plus Puerto Rico issue mDLs that meet ISO/IEC 18013-5, and AAMVA already runs a Digital Trust Service that works like a lightweight version of the federal trust anchor in my design. The PKI, issuance flow, and proximity transfer are shipping software.

The soft spots are people and politics:

• Adoption is low. Roughly 7% of eligible cardholders had activated an mDL by the end of 2025, ranging from about 21% in Arizona to 1% in Alaska.

• Wallets are fragmented. Apple, Google, Samsung, and state apps don't play nicely together yet.

• The label is the real obstacle. Formalizing a federal root across fifty states sets off the "national ID" alarm no matter how private the architecture is. I'd guess 3 to 5 years of engineering, with the clock set by political will, not code.

• Nobody owns it. NIST, DHS, and SSA each hold a piece and nobody's been told to run the thing. The real ask isn't "build it." It's "pick a lead agency."

Where my design is weakest#

A write-up that only lists strengths is a sales pitch, so here's the other column.

1. Revocation can leak. If verifiers check revocation status live, the issuer can learn a credential was presented. Status lists and caching help, but freshness versus privacy is a real tension.

2. Query logging. Even with no new data collection, logs of who verified what and when can turn into a behavioral profile if anyone keeps them.

3. New attack surface. Exposing existing DMV databases through issuance APIs creates endpoints that didn't exist before.

4. BBS+ is the immature part. mDL and SD-JWT are deployed. Unlinkable BBS+ proofs are still being standardized, so treat that layer as the ambitious bit.

5. Fifty implementations. Security quality will vary by state, and one weak state is a weak link in the chain unless the audit regime has teeth.

What I built along the way#

This spawned a small pile of artifacts: the ten-flow journey map, a mobile version, a one-pager for non-technical staff, and a 16-slide interactive deck with live charts. I might post those later.

If you spot a hole in the design, tell me. The contact page is the fastest way.