!!! Overview
[{$pagename}] is a [Hyperledger Project|Hyperledger] for supporting independent identity on [Permissioned Systems] [Public Ledger] [Distributed Ledger Technology] and part of the [Linux Foundation]


[{$pagename}] is used by the [Sovrin Foundation]


[{$pagename}] provides accessible [provenance] for [trust] to support user-controlled exchange of [Verifiable Claims] about an [identifier]. 

[{$pagename}] also has a rock-solid [revocation model] for cases where those [claims] are no longer true. [Verifiable Claims] are a key component of [{$pagename}]’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 [{$pagename}] [architecture] as reflected by three fundamental features:
* [identifiers] on _[{$pagename}] are [Pairwise Pseudonymous Identifiers] by default to prevent [Identity Correlation]. [{$pagename}] 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 [{$pagename}]’s pairwise identifier architecture.
* [personal data] is never written to the [{$pagename}]. 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].
* [{$pagename}] 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.

[{$pagename}] is all about giving identity owners independent control of their [personal data] and [relationships]. [{$pagename}] 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|Third-party] 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]

!! [{$pagename}] [Source code]
[{$pagename}] 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 [{$pagename}] 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.

[{$pagename}] 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|Sovrin 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|Create] 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Hyperledger Geting Started|https://github.com/hyperledger/indy-sdk/blob/rc/doc/getting-started/getting-started.md|target='_blank'] - based on information obtained 2018-09-30- 
* [#2] - [Indy SDK|https://github.com/hyperledger/indy-sdk/tree/rc|target='_blank'] - based on information obtained 2018-09-30- 
* [#3] - [Hyperledger-github|https://github.com/hyperledger|target='_blank'] - based on information obtained 2018-09-30-