iden3

• Name: iden3
• URL: https://iden3.io/
• Category: self-sovereign identity protocol / claim-and-proof infrastructure / zero-knowledge authentication layer / credential state-anchoring system
• Summary: iden3 is claim-tree plumbing, not a consumer identity app. The point is the protocol shape: structured claims, sparse-Merkle identity state, revocation and versioning, zk-friendly proof queries, and login flows built around authorized keys. That makes it useful beneath later packaging such as Privado ID and beside attestation or DID rails, but it is not itself a proof-of-personhood system.
• What it does:
  • Lets an identity issue claims about itself or another identity, with claims expressed in a protocol-defined structure rather than as arbitrary app-side blobs
  • Stores claims in sparse deterministic Merkle trees whose roots feed into identity state and can be anchored on EVM chains
  • Supports revocation, claim versioning, and proofs that a claim was issued by a given identity, is not revoked, and is the latest version when applicable
  • Provides a login / identity-assertion flow based on authorized signing keys, challenge nonces, proof-of-claim verification, and signed packets
  • Exposes a broader developer stack of crypto libraries, circuits, proof generation, authentication tooling, and standards-oriented claim/query layers
  • Positions itself as interoperable with DID, JSON-LD, JSON Schema, and W3C verifiable-credential style workflows while remaining optimized for zk-capable verification
• Key claims:
  • The official docs say the main idea of the iden3 protocol is that each identity is self-sovereign and can issue claims on another identity. That is the core reason to keep it distinct from later wallet or app brands: it is a general claim/identity protocol, not merely a verifier product.
  • The protocol spec is the most analytically important source in this pass. It shows that claims are not just attestations in the abstract: they have an explicit index/value structure, can be updated or revoked, and live inside sparse deterministic Merkle trees whose roots are indirectly stored on blockchain.
  • The identity model is unusually concrete. The docs define identity through issued and received claims, Genesis ID construction, and later identity-state publication, which makes onchain state anchoring a first-class part of the design rather than an optional add-on.
  • The spec also makes a useful trust distinction: protocol machinery can prove issuance, non-revocation, and freshness, but not the real-world truth of a claim’s content. That clarifies where credibility moves from cryptography into issuer reputation.
  • The login protocol matters because it shows iden3 trying to standardize authenticated identity assertion, not only credential storage. The docs describe challenge nonces, timeout handling, authorized kSign keys, proof-of-claim verification, and signed identity-assertion packets tied to server origin.
  • The official site adds two more useful control-plane details: a proof-query language for asking for only the claims needed, and an ID sponsor model intended to subsidize blockchain interaction for users. Those features matter because they affect who composes proof requests and who pays for practical identity usage.
  • iden3 is also historically important as a lower layer under later Polygon ID / Privado ID work and as the originator of Circom, which the official site highlights as part of the stack rather than an unrelated side project.
• Whitepaper: No single canonical whitepaper surfaced in this pass. The strongest primary materials were the official site plus the official protocol and login documentation collected in ../whitepapers/iden3-primary-sources-2026-05-10.md.
• Sources:
  • https://iden3.io/
  • https://docs.iden3.io/
  • https://docs.iden3.io/protocol/spec/
  • https://docs.iden3.io/services/login-protocol/
  • https://github.com/iden3/docs

Internal linkages

• Start with privado-id. It is the clearest downstream packaging of the same claim-tree and zk-proof stack.
• Use ethereum-attestation-service as the cleaner contrast for a shared public attestation rail.
• Keep world-id as the heavier-policy comparison where the fight is over who counts, not how claims are structured.

Control surface

• The durable machinery is the claim-tree and state-root design. The trust still sits with issuer credibility, revocation handling, sponsor policy, and whatever app or server composes the proof request.

• iden3 is strongest as identity-claim plumbing. Do not let the note drift into a generic human-verification bucket.

• Last reviewed: 2026-05-28 UTC