STRATEGYMonths to result

Identifier-Authenticator Separation Model

Stop using personal data as passwords—authenticate with cryptographic keys instead.

Problem it solves

Organizations rely on personal identifiers—SSN, name, biometrics—as authentication secrets, but this data is permanently compromised and non-rotatable, creating an unfixable structural vulnerability at scale.

Best for

Fraud risk managers, identity architects, and product teams redesigning authentication flows for financial services, government, or high-assurance digital systems.

Not ideal for

Simple internal tools or low-stakes applications where identity verification is not a meaningful attack surface and no sensitive user data is at risk.

Overview

Why this framework exists

The Identifier-Authenticator Separation Model addresses a foundational flaw in modern identity systems: personal identifiers—name, SSN, face, fingerprint—are being treated as authentication secrets. These 'secrets' are massively compromised and cannot be rotated. Unlike passwords, you cannot change your face. The model prescribes replacing identifier-based authentication with cryptographic key pairs: private keys sign attestations, public keys verify authorship. This transforms authentication from a knowledge-based (what you know) or biometric (what you are) model into a mathematically provable ownership model (what you control). Credentials are issued to a user's decentralized identifier rather than their PII, enabling revocation of specific credentials without destroying the user's foundational identity.

Core principles

6 total
  1. Personal identifiers (SSN, biometrics, name) are already public knowledge—treat them as such, never as secrets.
  2. Non-rotatable data (face, fingerprint) should never be the last line of authentication defense.
  3. Presume all centralized identity data will eventually be compromised.
  4. Cryptographic key pairs provide mathematically provable authorship that cannot be spoofed with stolen data.
  5. Separating the credential from the identifier preserves user identity even when specific credentials are revoked.
  6. Open standards prevent new centralized chokepoints from replacing the old ones.

Steps

6 steps
  1. Audit existing authentication flows
    Map every authentication touchpoint and classify each as identifier-based (uses SSN, DOB, address, or biometrics as the secret) or cryptographic (uses key pairs). This audit reveals the full structural vulnerability surface across the organization.
    Pro tipFlag any system where a fraudster could authenticate by simply knowing or presenting personal data—these are your highest-risk flows regardless of how many data points they require.
    WarningBiometric systems may appear more secure than SSN-based auth but are still identifier-based; classify them in the same high-risk bucket.
  2. Adopt a 'presume compromised' posture
    Treat all personal identifier data as if it has already been breached. Redesign controls with the assumption that any attacker already possesses the user's name, SSN, DOB, address, and biometric templates from existing dark web data dumps.
    Pro tipRun tabletop exercises assuming full PII compromise and ask: 'What controls would still hold?' Only those are worth keeping.
    WarningDo not substitute one biometric for another (replacing SSN auth with facial recognition) and treat it as a fix—you are trading one non-rotatable secret for another.
  3. Implement cryptographic key pair authentication
    Replace identifier-based auth with private/public key cryptography. Users sign attestations with their private key; verifiers check the digital signature against the public key, providing mathematical proof of authorship rather than probabilistic inference from data.
    Pro tipUse open standards (W3C DIDs, Verifiable Credentials) to ensure interoperability and avoid creating new proprietary lock-in.
    WarningCryptographic auth proves authorship, not trustworthiness—a signed message proves who sent it, not whether the underlying claim is accurate.
  4. Issue credentials to decentralized identifiers, not PII
    When a credential (driver's license, age verification, professional certification) is issued, anchor it to the user's DID—a public key they control—rather than their government-issued PII. This separates credential validity from personal data.
    Pro tipModel this after Utah's SEDI legislation: a credential can be revoked without revoking the user's foundational identifier, preserving their ability to function in other digital and physical contexts.
    WarningIf the DID anchor is centralized (DNS-dependent or corporate-controlled), you have reproduced the original censorship and revocation problem at a new layer.
  5. Enable selective disclosure for credential presentation
    Design credential presentation flows using zero-knowledge proof techniques so users prove specific attributes (over 21, licensed to drive) without revealing the underlying data (birthdate, full license details). The verifier gets confirmation of the attribute, not a copy of the document.
    Pro tipW3C Verifiable Credentials and existing ZKP libraries provide reference implementations for selective disclosure without building from scratch.
    WarningIf selective disclosure is not built into the architecture, systems will default to full document presentation and storage, defeating the privacy purpose.
  6. Build for key rotation and identity resilience
    Design identity systems so users can rotate cryptographic keys without losing credential history or access rights. Test revocation flows explicitly to confirm that a revoked credential removes specific access without destroying the user's broader digital identity.
    Pro tipSelf-contained key registries such as KERI or XID provide cryptographic continuity across key rotations with no external infrastructure dependency.
    WarningSystems that tie the credential subject to the identifier rather than the DID will effectively destroy the user's identity when a credential is revoked—a critical design failure.

Checklist

Saved in your browser

Examples

3 cases
Utah SEDI Legislation

Utah's State Endorsed Digital Identity law allows residents to bring their own public identifier and receive a state-issued credential anchored to that identifier. If a driver's license is revoked for repeated violations, the credential becomes invalid but the user's foundational identifier remains intact—they are not stripped of their entire digital identity, only the specific credential to drive.

OutcomeUsers retain control over their foundational identity infrastructure even when specific credentials are revoked by authorities.
Rabbit Hole Recap Nostr Signing

The podcast RHR publishes episode notes signed with its Nostr private key, providing cryptographic proof of authorship. Followers verify the signature against the account's public key without relying on platform-level trust or probabilistic document matching—authorship is proven by math, not by presentation of personal data.

OutcomeSpoofing the account requires controlling the private key, not just knowing account details—authorship verification becomes structurally unforgeable.
Traditional KYC as Counter-Example

A financial institution authenticates customers using SSN, DOB, and address—all available in dark web data dumps. A fraudster with a purchased data set passes knowledge-based authentication and opens fraudulent accounts. Adding biometric verification replaces one non-rotatable secret with another, providing no structural improvement.

OutcomeIdentity theft scales with data breach volume, with no architectural fix available within the identifier-as-authenticator model.

Common mistakes

3 traps
Replacing SSN auth with biometric auth
Biometrics appear more secure but are equally non-rotatable and already being compromised from centralized stores. Switching from SSN to facial recognition is a lateral move, not a structural fix—you still cannot recover when the biometric template is stolen.
Trusting vendor promises about biometric deletion
Private verification companies often claim to delete biometric data post-session, but there is no reliable enforcement mechanism. System architecture should not require this trust—design so that non-rotatable biometric data is never centrally stored in the first place.
Anchoring DIDs to centralized infrastructure
A decentralized identifier anchored solely on DNS or a corporate-controlled platform inherits that platform's censorship and revocation risks. The result is a cryptographically signed identifier that can still be taken away by a third party—reproducing the original problem with more technical complexity.

Origin story

How this framework came to be

Extracted from a TFTC interview with Gerald Glickman, a fraud and identity risk management practitioner who identified this structural flaw through years of work in financial services, major verification companies during COVID, and public sector identity programs.

Source

Traced to primary
Source · VIDEO
The Digital ID Trap Is Closing Faster Than You Think (your version, lock as-is) — TFTC
TFTC · 2026
Open source →

Related frameworks

Browse all Strategy →