did:indy
Identity Protocol
Comunidade
Links
Detalhes
Licença Libre (Apache-2.0) — indy-node (server) and indy-vdr / indy-sdk successors at https://github.com/hyperledger-indy
Status de Dev 🟢 Ativo
Proprietário LF Decentralized Trust (Linux Foundation) — Hyperledger Indy project; did:indy specification contact listed in the W3C registry is Stephen Curran. Individual Indy networks are operated by separate governing bodies, historically the Sovrin Foundation for the Sovrin networks
Órgão de Governança LF Decentralized Trust (Hyperledger Indy codebase) | Per-network consortium (network operation and endorser authority under each network's own governance framework)
País International — LF Decentralized Trust is a Linux Foundation project; individual networks are operated by geographically distinct consortia
Ano de Início 2017
Stack Python and Rust — indy-node written in Python; indy-vdr and related client libraries in Rust with bindings; RBFT consensus
Financiamento Foundation — LF Decentralized Trust (Linux Foundation) project funding; individual networks funded by their operating consortia (historically the Sovrin Foundation)
Última Investigação 1 de jul. de 2026
Identity Protocol Atributos
Origins Self-sovereign identity — the founding infrastructure of the SSI movement, built by the Sovrin Foundation specifically for privacy-preserving verifiable credentials rather than as a general-purpose blockchain
Database Hyperledger Indy ledger — a purpose-built permissioned distributed ledger using RBFT consensus, storing DIDs, schemas, credential definitions and revocation registries
Query Language Indy ledger read requests via indy-vdr; DID resolution through Indy-aware resolvers. Reads are permissionless even where writes are not
Data Formats W3C DID Document derived from Indy NYM and ATTRIB ledger transactions; Indy-native schema and credential-definition objects; historically paired with AnonCreds credential format rather than plain W3C VCs
Mobile Support Library-level — implemented inside resolver libraries and wallets; no standalone application
Web Support Library-level — resolution reads the Indy ledger through resolver libraries or a hosted universal-resolver endpoint; DID documents are not web-hosted
Native Apps Library-level — embedded in resolver libraries; no standalone application
Terms Free to read; writing requires an endorser role under the target network's governance framework, which some networks charge for and others grant administratively
Funds Unknown — no consolidated figures published
Based On W3C DID Core 1.0; Hyperledger Indy ledger and RBFT consensus; the Sovrin governance framework model. Successor work: Indy Besu (Hyperledger Besu-based re-platforming)
Permissions Role-based on-ledger — endorser, steward and trustee roles defined by the network's governance framework determine who may write; key control determines who may update a given DID
Authentication & Identity Ledger-anchored — the DID and its keys are recorded on an Indy network and resolved from it; authority to write is mediated by an endorser under the network's governance framework rather than by key possession alone
Storage Model Distributed ledger — replicated across the network's validator nodes with RBFT consensus; no personally identifying data is written on-chain by design, only DIDs, schemas, credential definitions and revocation registries
Interoperability Strong within the Indy/Aries lineage — Aries agents, AnonCreds credentials and the OpenWallet Foundation successors. Interoperability with the wider W3C VC ecosystem historically required bridging, since AnonCreds is not a W3C VC format, though convergence work has narrowed this
Data Portability Limited — identifiers are bound to the Indy network they were written to and cannot be migrated to another network or method without re-issuance. Credentials issued against them break if the network is retired
Governance & Decision Making Two layers — the codebase is governed by LF Decentralized Trust open-source process, while each running network is governed by its own consortium under a published governance framework defining endorser roles and write authority. The Sovrin governance framework was the reference model
Protocol Maturity / Standardization Registered W3C DID method with years of production deployment on stable networks. The method specification is a community document rather than a W3C Recommendation, and the surrounding ecosystem is in transition — Aries archived into the OpenWallet Foundation, Indy Besu positioned as the successor platform
Identity Standards W3C DID Core 1.0; AnonCreds (Indy's native ZKP credential format); Hyperledger Aries protocols (now under OpenWallet Foundation); registered in the W3C DID Extensions methods registry
DID Methods Supported did:indy (defines this method), with a network identifier segment allowing the same method to address multiple independent Indy ledgers. Historically preceded by the legacy did:sov method on Sovrin networks
Key Management Ledger-recorded rotation — verkey rotation is written to the ledger as a NYM transaction signed by the current key, giving auditable key history. Rotation requires a ledger write and therefore network availability
Credential Types N/A — a DID method specification; defines no credential types. Compatible with W3C Verifiable Credentials issued against identifiers of this method
Verification Method Ledger lookup — the resolver reads the DID's current state from an Indy network; correctness depends on the ledger's RBFT consensus and on reaching an honest node, not on self-certification
Privacy Features Strong at the credential layer, weaker at the identifier layer — AnonCreds provides zero-knowledge selective disclosure and unlinkable presentations, historically the most privacy-capable credential format in production. But public DIDs on a public-read ledger are inherently visible, so the design intent is that only issuers hold ledger-written DIDs while holders use pairwise peer DIDs
Authentication Methods Cryptographic signature against the verkey recorded on the ledger
Revocation Mechanism Ledger-based — DIDs can be deactivated by ledger transaction; credential revocation uses Indy revocation registries with cryptographic accumulators supporting non-revocation proofs
Agent Types Supported Any key-controlling entity — individuals, organizations, services and devices
Wallet/Client Types SDK / library integration — resolver implementations across the SSI tooling ecosystem; no method-specific wallet
Recovery Mechanisms Verkey rotation by the controlling key; where the controlling key is lost, recovery depends on the network's governance framework and endorser intervention rather than on a cryptographic mechanism
Compliance / Regulations Designed for regulatory legibility — permissioned governance frameworks with identifiable, accountable operators made Indy the substrate for several government and provincial identity programmes. No personally identifying data is written on-chain, which supports GDPR alignment
Credential Exchange Protocols Aries protocols (DIDComm-based issuance and presentation), now continuing under the OpenWallet Foundation; AnonCreds presentation exchange
Trust Framework Governance-framework based — trust derives from the published rules of the operating consortium (endorser roles, transaction authorship agreements, steward obligations) layered on ledger consensus. This is explicit institutional trust rather than pure cryptography
Cost Model Network-dependent — reads are free; writes require endorser authority, which some networks price and others grant administratively under their governance framework
Censorship Resistance Moderate — the ledger itself is replicated across independent stewards and resistant to single-node failure, but write access is permissioned, so a governing consortium can decline to endorse an identifier. Reading and resolving existing DIDs is not censorable by any single steward