Overview#

Hyperledger Indy is a Hyperledger Project for supporting independent identity on Permissioned Systems Public Ledger Distributed Ledger Technology and part of the Linux Foundation

Hyperledger Indy is used by the Sovrin Foundation

Hyperledger Indy provides accessible provenance for trust to support user-controlled exchange of Verifiable Claims about an identifier.

Hyperledger Indy also has a rock-solid revocation model for cases where those claims are no longer true. Verifiable Claims are a key component of Hyperledger Indy’s ability to serve as a universal platform for exchanging trustworthy claims about transactions. Provenance is the foundation of accountability through recourse.

Another vital feature of Decentralized Identifier entity & ??;especially for a public ledger—is privacy. Privacy by Design is baked deep into Hyperledger Indy architecture as reflected by three fundamental features:

• identifiers on _Hyperledger Indy are Pairwise Pseudonymous Identifiers by default to prevent Identity Correlation. Hyperledger Indy is the first Distributed Ledger Technology to be designed around Decentralized Identifiers (DIDs) as the primary keys on the ledger. Decentralized Identifiers on the ledger point to DID descriptor objects (DDOs), signed JSON Objects that can contain Public Keys and service endpoints for a given identifier. Decentralized Identifier are a critical component of Hyperledger Indy’s pairwise identifier architecture.
• personal data is never written to the Hyperledger Indy. Rather all private data is exchanged over Peer-to-peer Encrypted connections between off-ledger agents. The ledger is only used for anchoring rather than publishing encrypted data.
• Hyperledger Indy has built-in support for Zero-knowledge proofs (ZKP) to avoid unnecessary disclosure of identity Attributes—privacy preserving technology that has been long pursued by IBM Research (Identity Mixer) and Microsoft (U-Prove), but which a public ledger for decentralized identity now makes possible at scale.

Hyperledger Indy is all about giving identity owners independent control of their personal data and relationships. Hyperledger Indy is built so that the owner of the Digital Identity is structurally part of transactions made about that identity. Pairwise Pseudonymous Identifiers stop third parties from talking behind the identity owner’s back, since the identity owner is the only place Pairwise Pseudonymous Identifiers can be correlated.

Indy#

Indy is an Abbreviation for Independent Identity

Hyperledger Indy Source code#

Hyperledger Indy original Source code was donated to Sovrin Foundation by Evernym INC. who then contributed it to the Linux Foundation

DID Classification#

Creation of a DID that is known to the Hyperledger Indy is know as a Verinym, and the transaction used for creating a Verinym is known as a NYM transaction.

NYM Transaction#

NYM record is created by a for a specific user, Trust Anchor, Sovrin Stewards or trustee. Note that only trustees and Sovrin Stewards can create new Trust Anchors and a trustee can be created only by other trustees.

The transaction can be used for creation of new DIDs, setting and Key Rotation of verification key, setting and changing of roles.

Hyperledger Indy Transaction contains:

• dest (base58-encoded string):
  • Target DID as base58-encoded string for 16 or 32 byte DID value. It differs from the from metadata field, where from is the DID of the submitter. Example: from is a DID of a Trust Anchor creating a new DID, and dest is a newly created DID.
• role (enum number as integer; optional): Role of a user that the NYM record is being created for. One of the following values
  • None (common USER)
  • 0 (TRUSTEE)
  • 2 (STEWARD)
  • 101 (TRUST_ANCHOR)
  • A TRUSTEE can change any Nym’s role to None, thus stopping it from making any further writes.
• verkey (base58-encoded string, possibly starting with “~”; optional): Target verification key as base58-encoded string. It can start with “~”, which means that it’s an abbreviated verkey and should be 16 bytes long when decoded, otherwise it’s a full verkey which should be 32 bytes long when decoded. If not set, then either the target identifier (did) is 32-bit cryptonym CID (this is deprecated), or this is a user under guardianship (doesn’t own the identifier yet). Verkey can be changed to “None” by owner, it means that this user goes back under guardianship.
• alias (string; optional): NYM’s alias.

If there is no NYM transaction for the specified DID yet, then this can be considered as the creation of a new DID.

If there is already a NYM transaction with the specified DID, then this is is considered an update of that DID. In this case only the values that need to be updated should be specified since any specified one is treated as an update even if it matches the current value in ledger. All unspecified values remain unchanged.

So, if Key Rotation needs to be performed, the owner of the DID needs to send a NYM request with did and verkey only. role and alias will stay the same.

More Information#

There might be more information for this subject on one of the following:

• Hyperledger
• Indy Steward
• Plenum Byzantine Fault Tolerant Protocol
• Sovrin
• Sovrin Agent
• Sovrin Ledger
• Sovrin Steward
• Verinym
• Verkey

---

• [#1] - Hyperledger Geting StartedContent unavailable! (broken link)https://ldapwiki.com/wiki/images/out.png - based on information obtained 2018-09-30-
• [#2] - Indy SDKContent unavailable! (broken link)https://ldapwiki.com/wiki/images/out.png - based on information obtained 2018-09-30-
• [#3] - Hyperledger-githubContent unavailable! (broken link)https://ldapwiki.com/wiki/images/out.png - based on information obtained 2018-09-30-