Contextual Trust Ladder
Match identity verification depth to relationship context—never over-identify.
The Contextual Trust Ladder, influenced by Christopher Allen's self-sovereign identity work, treats digital trust as contextual and progressive rather than binary. Just as physical relationships develop incrementally—sharing more information as mutual trust deepens—digital identity verification should scale to the actual risk of each interaction. Low-stakes contexts require minimal verification; high-stakes contexts warrant more. The core discipline: always request the minimum information necessary for the specific context, using selective disclosure to prove attributes without exposing underlying personal data. This prevents normalization of over-identification, which creates the infrastructure for authoritarian surveillance regardless of the intent behind its construction.
- Trust is contextual—there is no single universal verification standard appropriate for all interactions.
- Trust is progressive—relationships earn disclosure; disclosure does not create trust.
- Always request the minimum information necessary for the specific context, nothing more.
- Selective disclosure proves required attributes without exposing underlying personal data.
- Avoid over-identification simply because identification has become technically easier.
- Third-party validators should be involved only when self-attested credentials genuinely do not suffice.
- Define the interaction context and relationship typeBefore specifying any identity requirement, clearly articulate the context: Is this a commercial transaction, social interaction, age-restricted content access, or financial service? Context is the primary determinant of appropriate verification depth.Pro tipBuild a trust context map for your product—list every interaction type and its inherent risk level before designing any verification flow.WarningMixing contexts—applying financial-grade verification to content access—is the primary mechanism through which over-identification normalizes.
- Assign a required assurance levelClassify each context as low (social posting, news reading), medium (e-commerce purchase, account creation), or high assurance (financial account opening, age-restricted access). Let the assurance level—not liability anxiety—drive verification requirements.Pro tipAsk: 'What is the worst-case fraud outcome if verification fails here?' Size the requirement to the actual risk, not the maximum imaginable risk.WarningDefaulting to high assurance across all contexts to cover liability is how unnecessary biometric and document collection proliferates.
- Identify the minimum necessary attributesFor each assurance level, list the specific attributes—not documents—needed to proceed. 'Must be over 21' is an attribute. 'Must present a full government ID' is over-collection unless the context specifically demands every field on that document.Pro tipWork backward from the attribute you need (age ≥ 21) to the minimum proof required (a signed credential asserting age ≥ 21), not forward from the most complete document available.WarningCollecting full identity documents 'just in case' creates data liability and violates the minimum-necessary principle even if the intent is benign.
- Deploy selective disclosure for credential presentationUse verifiable credentials and zero-knowledge proof techniques to let users prove specific attributes without revealing underlying data. A user proves they are over 21 without disclosing their birthdate, address, or any other field on their identity document.Pro tipW3C Verifiable Credentials and ZKP libraries provide existing selective disclosure infrastructure—don't build from scratch.WarningIf the verification infrastructure does not support selective disclosure natively, systems default to full document presentation and storage, creating the privacy exposure you sought to avoid.
- Involve third-party validators only when claims truly warrant itFor high-stakes contexts where self-attested credentials are insufficient, bring in trusted third-party issuers (government agencies, licensed institutions) to validate specific claims. Limit this escalation to genuinely high-risk interactions, not as a blanket policy.Pro tipA DMV-issued verifiable credential asserting age ≥ 21 can be verified cryptographically by a business without the business contacting the DMV or retaining any personal data.WarningRouting all verification through a single third-party issuer creates a correlation risk—that issuer can track user activity across every site that calls it.
A bar requires proof of age and nothing else. Rather than presenting a full driver's license revealing name, address, birthdate, and photo, a patron presents a cryptographically signed verifiable credential from the DMV asserting only that they are 21 or older. The bar's system verifies the signature and the attribute without retaining any personal data.
Publishing a post on a social network is a low-assurance context. A user signs the post with their Nostr private key. Followers verify authorship via the public key—no government ID, no biometric, no personal data exchange required. The verification depth matches the actual risk of the interaction.
Opening a brokerage account requires high assurance. The user presents a government-issued verifiable credential anchored to their DID plus a proof-of-address credential—only the attributes required by regulation. The institution verifies cryptographic signatures rather than storing physical document images indefinitely.
Significantly influenced by Christopher Allen's work on self-sovereign identity and contextual trust. Extracted from a TFTC interview with Gerald Glickman, identity fraud and risk management practitioner with public and private sector experience.