Resilient Identity Continuity

Maintain the ability to prove identity attributes on-chain after the original credential issuer becomes unavailable, hostile, or ceases to exist. Extends Private Identity to an issuer-hostile threat model: the issuer may refuse new issuance, mass-revoke credentials, publish false revocation lists, or go permanently offline. Holders need credential survival, recovery without issuer cooperation, and verification that requires no issuer or registry contact.

Additional Context

Resilience here is the product of plurality. A single issuer is a single point of failure; composing credential sources with per-identity cost scaling in ~N² (see Vitalik's zk-identity framework) distributes dependence across issuers that fail independently. Human Passport ships this shape for grant sybil resistance today; TACEO operates a 13-node threshold vOPRF that removes the issuer from the on-chain correlation path.

Related work and deployments:

  • Passport enrollment: ZKPassport (120+ country passports, NFC + Noir); Self
  • National ID: Anon Aadhaar (Indian Aadhaar, RSA signature verification)
  • Biometric: World ID (25M+ registrations)
  • Merkle membership: Semaphore (PSE)
  • Email identity: zkEmail (DKIM proofs)
  • TLS proofs: TLSNotary (web2 data export)

Actors

Holder (identity owner: enrolls once, proves attributes at will) · Identity Source (government document, email provider, biometric system, community attestation, civil registry) · Enrollment Operator (sybil-resistant enrollment gating, may be distributed) · Verifier (smart contract, institution, or dApp that checks proofs) · Auditor / Regulator (entity with scoped disclosure rights) · Governance Operator (manages on-chain trust anchor and operational parameters)

Problems

Problem 1: Credential Survival After Issuer Failure

Credential systems today depend on a live, cooperative issuer for revocation checks, re-issuance, and status queries. If the issuer goes offline, mass-revokes, publishes false revocation lists, or becomes adversarial, holders lose the ability to prove legitimately issued attributes. This is a single point of failure across all issuer-dependent identity systems.

Requirements:

  • Must survive: issuer shutdown, mass revocation, adversarial behavior (false status reports, credential forgery for non-holders, refusal of new issuance)
  • Must support: continued proof generation and verification after issuer destruction; new enrollments without the original issuer
  • Must not require: issuer online status for any post-enrollment operation
  • Must hide: holder identity, credential contents, issuer-holder relationship
  • Public OK: trust anchor state (e.g., commitment root), proof validity (pass/fail), scope-bound nullifiers
  • Auditor access: selective disclosure grants scoped read access to specific credential attributes or proof metadata
  • Ops: proof generation practical on consumer hardware; verification completable in a single on-chain transaction

Problem 2: Plural Enrollment Sources

Monolithic enrollment concentrates issuer risk and excludes anyone without the mandatory credential. Plural identity treats sources as composable rather than substitutable: passports for strong legal attestations, national IDs or email for web services, social vouches or economic stake for communities. Each signal is partial; together they cover disjoint populations and distribute issuer dependence, so failure of any one source degrades gracefully rather than catastrophically.

Requirements:

  • Must support: document-based (passport NFC, national ID), biometric-enrollment-based, email-based (DKIM), TLS-based (web2 data export), community attestation, civil registry
  • Must not require: any single credential source as mandatory
  • Sybil resistance: per-source mechanisms must prevent duplicate enrollment within a source type
  • Interop: credentials from different sources should be composable where possible
  • Constraints: some sources require the identity provider's cryptographic infrastructure to have existed at some prior point

Problem 3: Recovery Without Issuer Cooperation

Key loss in issuer-independent systems is permanent unless recovery mechanisms exist. Traditional recovery flows depend on the issuer re-issuing credentials. When the issuer is unavailable, hostile, or destroyed, holders need alternative paths to restore their ability to prove identity attributes.

Requirements:

  • Must support: threshold recovery (secret sharing across devices or custodians)
  • Must support: social recovery (guardian-based, quorum-authorized key rotation)
  • Must not require: issuer participation in any recovery flow
  • Anti-coercion: recovery participants cannot be compelled to reveal which holder they are protecting
  • Constraints: recovery must not create a duplicate identity; must bind to the holder's original enrollment

Problem 4: Universal Verification Without Registry or Issuer Contact

Verification in existing private identity systems often requires contacting a registry operator or issuer for revocation checks or credential status. In an issuer-hostile setting, verification must work with the on-chain trust anchor and a ZK proof, without external service calls.

Requirements:

  • Must support: any verifier (on-chain or off-chain) with no issuer or registry contact
  • Must support: degraded operation (holder generates proofs locally; verifier checks against a cached or on-chain trust anchor)
  • Must preserve: unlinkability across verifiers and sessions
  • Ops: verification gas costs practical for frequent access checks; scope-bound nullifiers prevent replay without linking proofs

Recommended Approaches

Challenge Strategy Key Property
Credential anchoring On-chain commitment via distributed enrollment No issuer dependency after enrollment
Sybil resistance Layered (cryptographic + economic + social) Degrades gracefully when credential sources are compromised
Recovery Threshold (Shamir) + social (guardian-based) No issuer participation required
Verification Universal (on-chain trust anchor + ZK proof) Any verifier, no registry contact

See Approach: Private Identity, Section F for detailed architecture and trade-offs.

Open Questions

  • What is the minimum guardian set size for social recovery that provides anti-coercion guarantees without excessive coordination overhead?
  • How does recovery interact with the original enrollment? Can a recovered identity reuse original identifiers, or must new ones be derived deterministically?
  • How do identity sources that require prior provider infrastructure handle retroactive deletion of cryptographic evidence by the provider?
  • What models enable credential attribute freshness without an issuer to refresh them (e.g., expired passports, changed nationality)?
  • What is the production path for private predicate parameters, so that verification transactions do not leak which attribute is being queried?

Notes And Links