Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo. Indy is interoperable with other blockchains or can be used standalone powering the decentralization of identity.
{% include figure image_path="/images/private-public-permissioned-permissionless.webp" alt="this is a placeholder image" caption="@Delpadschnick | [CryptoDesign.io](https://CryptoDesign.io)" %}
> Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo.
> This codebase embodies all the functionality to run nodes (validators and/or observers) that provide a self-sovereign identity ecosystem on top of a distributed ledger. It is the core project for Indy; over time, all other indy-* projects may collapse into this one, except for indy-sdk.
> This is the official SDK for Hyperledger Indy, which provides a distributed-ledger-based foundation for self-sovereign identity. Indy provides a software ecosystem for private, secure, and powerful identity, and the Indy SDK enables clients for it. The major artifact of the SDK is a C-callable library; there are also convenience wrappers for various programming languages and Indy CLI tool.
* [Strengthening Hyperledger Indy and Self-Sovereign Identity](https://www.hyperledger.org/blog/2019/07/18/strengthening-hyperledger-indy-and-self-sovereign-identity) 2019-07-08
> Forrester’s recent “[Top Recommendations for Your Security Program, 2019](https://www.forrester.com/report/Top+Recommendations+For+Your+Security+Program+2019/-/E-RES151535),” testifies to this, describing SSI as a “win” for customers and businesses, and urged chief information security officers (CISO) to “Empower your customers to control their own identities via self-sovereign identity.”
>
> They can do this because exchanging verifiable digital credentials is at the heart of SSI. This ends the need for massive data silos, honeypots, and unsecured data repositories housed at countless corporations and organizations. Instead, anyone can hold secure and verifiable information about themselves
* [An overview of Self-Sovereign Identity: the use case at the core of Hyperledger Indy](https://www.hyperledger.org/blog/2019/05/01/an-overview-of-self-sovereign-identity-the-use-case-at-the-core-of-hyperledger-indy) 2019-05-01
> Credential issuers, holders, and verifiers are peers on an SSI network. Any person or organization can play any or all of the roles, creating a decentralized system for the exchange of trustworthy, digital credentials.
>
> - Credential issuers determine what credentials to issue, what the credential means, and how they’ll validate the information they put in the credential.
> - Credential holders determine what credentials they need and which they’ll employ in workflows to prove things about themselves.
> - Credential verifiers determine what credentials to accept, and which issuers to trust.
> Lighting talk with Nathan George (Sovrin CTO) taking the audience through a high-level look at the Sovrin DLT, how it can be public/permissioned yet still decentralized, and why this is right for identity solutions.
> Individuals will not have to rely on big organizations to store and share their personal data. Instead the user controls what data they want to provide access to and for how long.
* [Implementing Privacy by Design in Hyperledger Indy](https://www.infoq.com/news/2018/09/Hyperledger-Indy-Privacy) 2018-09 Infoq
> Hyperledger Indy has been built using a privacy first approach. As the world shifts to more regulation, including GDPR and ePrivacy requirements, Indy can minimize the amount of details a user shares when having their data validated by a third-party system.
* [Privacy by Design in Hyperledger Indy](https://www.hyperledger.org/blog/2018/09/12/privacy-by-design-in-hyperledger-indy) 2018-09-12 Hyperledger Foundation
> Hyperledger Indy’s approach to privacy includes elliptic curve cryptography, [pairwise DIDs](https://docs.google.com/document/d/1hnQPEdfmAG-DnXGrDXowjc5J571pK7Ub4bWkUlzrH1Y/edit), [semi-trusted agents](https://docs.google.com/presentation/d/1H7KKccqYB-2l8iknnSlGt7T_sBPLb9rfTkL-waSCux0/edit#slide=id.g2f2a8bc547_0_0), [agent-to-agent communication](https://github.com/hyperledger/indy-hipe/blob/35c9a8fda2011763d85df2a57bccc67bcdc28760/text/transport-layer-messaging/README.md) using techniques such as [libsodium’s sealed box](https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html) and [authenticated encryption](https://download.libsodium.org/doc/public-key_cryptography/authenticated_encryption.html), zero-knowledge proofs, a separation between credentials and proofs, [privacy-preserving credential revocation](https://github.com/hyperledger/indy-hipe/blob/4fd9db5801f24f4e9ec122db98d4f725a394617c/text/0011-cred-revocation/README.md) features, an [affinity for data and key storage at the edge](https://docs.google.com/document/d/1Tcz06KtmnTysW38qT5K_oVzsWV9TjQFR4No9rRJEGFA/edit#heading=h.26in1rg), and a [carefully constructed wallet interface](https://github.com/hyperledger/indy-hipe/blob/36d3eddf4213b3a5f4bc9355cd6a645e819b1f31/text/wallets/README.md) that manages personal secrets with industry best practices. In addition, privacy-preserving [agent (device) revocation](https://github.com/hyperledger/indy-sdk/blob/677a0439487a1b7ce64c2e62671ed3e0079cc11f/doc/design/005-dkms/DKMS%20Design%20and%20Architecture%20V3.md#92-policy-registries) has been demonstrated as a proof of concept.
* [Blockchain for Business](https://www.edx.org/professional-certificate/linuxfoundationx-blockchain-for-business) 2018-07-10 Linux Foundation
> 2–4 hours per week, for 10 weeks. A primer to blockchain, distributed ledgers and Hyperledger technologies.
> You can store your identities in a location where you can edit or delete them. After giving the location of your identities, the Indy platform lists your location with a globally identifiable name. When someone wants to read your identity data, the Indy platform points out the location of your identities. Let’s look into the details of how it works.
> Indy is all about giving identity owners independent control of their personal data and relationships. Indy is built so that the owner of the identity is structurally part of transactions made about that identity. Pairwise identifiers not only prevent correlation, but they stop third parties from transacting without the identity owner taking part since the identity owner is the only place pairwise identifiers can be correlated.
* [Hyperledger completes development of DID:Indy Method and advances toward a network of networks](https://www.hyperledger.org/blog/2022/05/02/hyperledger-identity-community-completes-development-of-didindy-method-and-advances-toward-a-network-of-networks) 2022-05-02 Linux Foundation, Howland & Bluhm
> With the groundwork complete, networks and agent frameworks now need to incorporate the Indy:DID Method. This community adoption will increase the viability of the Indy and Aries project stack and position it to be the globally dominant way to issue and share verifiable credentials in a multi-ledger world.
* [Building a Hyperledger Indy Network](https://iiw.idcommons.net/1H/_Building_a_Hyperledger_Indy_Network_-_Questions,_discussion,_etc.) 2021-05-06 Lynn Bendixsen IIW
> This repo holds RFCs for the Indy project. We call them HIPEs (Hyperledger Indy Project Enhancements, pronounced like "hype" for short). They describe important topics (not minor details) that we want to standardize across the Indy ecosystem.
> "Byzantine fault tolerance is a sub-field of fault tolerance research inspired by the Byzantine Generals' Problem, which is a generalized version of the Two Generals' Problem."
* [Storage components](https://github.com/hyperledger/indy-plenum/blob/master/docs/storage.md) - As of now, RocksDB is used as a key-value database for all Storages.
* [indy-sdk](https://github.com/hyperledger/indy-sdk) - Everything needed to build applications that interact with an Indy distributed identity ledger.
* [hyperledger-labs/business-partner-agent](https://github.com/hyperledger-labs/business-partner-agent) 2023-05-17 - The Business Partner Agent allows to manage and exchange master data between organizations
> The current maintainers stop active contribution to the further development of the Hyperledger Labs project Business Partner Agent, as well as the related project Business Partner Agent Helm Chart. To give existing users of the Business Partner Agent enough lead time, we are willing to continue maintaining the project for now. For more information see the Hyperledger Discord channel.
* [IDunion](https://idunion.org/?lang=en)
> enables self-determined identities based on Self-Sovereign Identity (SSI) technologies Hyperledger Indy and Hyperledger Aries. The aim of the IDunion organisation is to create an open ecosystem for decentralised identity management, which can be used worldwide and is based on European values and regulations. IDunion is also a [project](https://www.digitale-technologien.de/DT/Redaktion/DE/Standardartikel/SchaufensterSichereDigIdentProjekte/Schaufensterprojekte/sdi-projekt_idunion.html)co-funded by the [German Federal Ministry of Economic Affairs (BMWi)](https://www.bmwi.de/Navigation/EN/Home/home.html)as part of the [Showcases Secure Digital Identities program](https://www.digitale-technologien.de/DT/Navigation/DE/ProgrammeProjekte/AktuelleTechnologieprogramme/Sichere_Digitale_Identitaeten/sichere_digitale_ident.html). We gave an introduction covering
* [BC Gov Collaboration on the Business Partner Agent, sharing our Roadmap (Create Creds, Issue them, Verify them, Hold them, publish them, ZKPs, Selective Disclosure)](https://iiw.idcommons.net/24A/_BC_Gov_Collaboration_on_the_Business_Partner_Agent,_sharing_our_Roadmap-Create_Creds,_Issue_them,_Verify_them,_Hold_them,_publish_them,_ZKPs,_Selective_Disclosure-)2021-05-06 Matthew Hall IIW
> - Viewing organizations as Issuers, Verifiers and Holders
> - Talked about the complexity of defining a verifiable credential, I.e. what are you attesting to?
> - Went over the need to make it easier for users to be able to create credential schemas and credential definitions without having to gain understanding about the tech.
* [IXO World](https://ixo.world/) - Guided by the UN framework of 17 Global Goals to end poverty, protect the planet and ensure prosperity for all, by the year 2030. [[**ϟ**](https://twitter.com/phillipgibb/status/1073247433067556865)] (ethereum ocean ipld)
>"Achieving the Sustainable Development Goals demands embracing the data revolution " UN Secretary - General (2014)
* [Legal Entity Identifier blockchained by a Hyperledger Indy implementation of GraphChain](http://web.archive.org/web/20220221134446/http://graphchain.io/MTSR2018.pdf) 2018-10-23
>The main idea behind GraphChain is to use blockchain mechanisms on top of an abstract RDF graphs. This paper presents an implementation of GraphChain in the Hyperledger Indy framework. The whole setting is shown to be applied to the RDF graphs containing information about Legal Entity Identifiers (LEIs).
> NB Orbit Enterprise is a no-code self-sovereign identity platform that facilitates the storage, issuance and verification of verifiable credentials that are held and owned by end users in digital wallets.
>
> The platform contains a collection of technologies and concepts in identity management, distributed and edge computing, distributed ledger technologies and cryptography.
* [A Framework for Designing Cryptographic Key Management Systems](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-130.pdf) 2023-06-12
> This Framework for Designing Cryptographic Key Management Systems (CKMS1) is a description of the topics to be considered and the documentation requirements (henceforth referred to as requirements) to be addressed when designing a CKMS. The CKMS designer satisfies the requirements by selecting the policies, procedures, components (hardware, software, and firmware), and devices (groups of components) to be incorporated into the CKMS, and then specifying how these items are employed to meet the requirements of this Framework
* [An automatized Identity and Access Management system for IoT combining SSI and smart contracts](https://arxiv.org/pdf/2201.00231.pdf) 2023-06-11Montassar Naghmouchi, Hella Kaffel, and Maryline Laurent
> This paper proposes a blockchain-based identity and access management system for IoT – specifically smart vehicles- as an example of use-case, showing two interoperable blockchains, Ethereum and Hyperledger Indy, and a self-sovereign
* [Technical Design and Development of a Self-Sovereign Identity Management Platform for Patient-Centric Healthcare Using Blockchain Technology](https://blockchainhealthcaretoday.com/index.php/journal/article/view/196#.Yjkahet3YEM.twitter) 2022-04-22Blockchain Healthcare Today
> To manage patient’s self-sovereign identity, we leveraged the Hyperledger Indy blockchain framework to store patient’s decentralized identifiers (DIDs) and the schemas or format for each credential type. In contrast, the credentials containing patient data are stored “off-ledger” in each person’s wallet and accessible via a computer or smartphone. We used Hyperledger Aries as a middleware layer (API) to connect Hyperledger Indy with the front-end, which was developed using a JavaScript framework, ReactJS (Web Application) and React Native (iOS Application).
* [Blockchain Trilemma for Decentralized Identity: Learning from Hyperledger Indy](https://arxiv.org/pdf/2204.05784.pdf)2022-04-12 Paul Dunphy, OneSpan, Cambridge, UK
> The current credential verification process relies on transaction processing by a ledger with transaction processing bottlenecks, which may constrain the ideal of non-repudiation.
* [Blockchain Trilemma for Decentralized Identity: Learning from Hyperledger Indy](https://arxiv.org/pdf/2204.05784.pdf) 2022-04-22Paul Dunphy, OneSpan, Cambridge, UK
> The current credential verification process relies on transaction processing by a ledger with transaction processing bottlenecks, which may constrain the ideal of non-repudiation.
* [Zero-Knowledge Proofs: Privacy-Preserving Digital Identity with Clare Nelson](https://www.slideshare.net/SSIMeetup/zeroknowledge-proofs-privacypreserving-digital-identity-with-clare-nelson)
* [What Zero Knowledge Poof Algorithm is used in Sovrin?](https://forum.sovrin.org/t/what-zero-knowledge-proof-algorithm-is-used-in-sovrin/71/2)
> Our zero-knowledge proofs are part of the [Idemix protocol](http://domino.research.ibm.com/library/cyberdig.nsf/papers/EEB54FF3B91C1D648525759B004FBBB1/%24File/rz3730_revised.pdf), where they are used to prove the possession of [Camenisch-Lysyanskaya credentials](https://eprint.iacr.org/2001/019.pdf). We also use zero-knowledge proofs in the revocation protocol, which is based on [cryptographic accumulators](https://eprint.iacr.org/2008/539.pdf).
