description: Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity.
excerpt: >
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
> - Does not require a centralized registration authority
> - Many DIDs use the distributed ledger technology or any other decentralized network, though it is not mandatory
> - It is a permanent identifier because it does not depend on a single third-party or centralized registry for its existence.
> - Can be cryptographically verified
> - They connect a DID subject (the entity identified by the DID) with a DID document (a set of data that describes the DID subject) to enable the subject to have trustable interactions.
> - They are interoperable and portable, provided they conform to the existing standards laid down by W3C
* [The world between public and private DIDs - Or how to make use of SSI without the subjects](https://iiw.idcommons.net/21D/_The_world_between_public_and_private_DIDs_-_Or_how_to_make_use_of_SSI_without_the_subjects)by This Loepfe, cardossier CH
> - It was very hard for me to explain the problem I’m searching a solution for and equally for the proposed solution ideas.
> - We discussed a lot of more philosophical questions and if peer-dids are a good thing or not and if it is worth trying to minimize correlation when any involved party anyway stores the personal data of the related persons. I think we should make it as hard as possible to correlate data, even if we can not completely prevent it.
> - We also discussed the potential complexity of such a solution and if it is worth it. The conclusion was to minimize the number of personas one should (be forced) to hold, such that it is still easy to maintain.
[DID 101 – Decentralized Identifiers & how they are the key to interoperable self-sovereign ID](http://iiw.identitycommons.net/1A/_DID_101_%E2%80%93_Decentralized_Identifiers_%26_how_they_are_the_key_to_interoperable_self-sovereign_ID)
> Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
> A DID architecture should focus on the set of components that Mr. Gupta refers to as "the minimum required for people to be able to do business (or other critical functions) together".
>
>**A Decentralized Identifier (DID) Registry and Discovery Service**
>
> This "minimum required" is defined by a union of the proposed requirements identified by the W3C Credential Community Group, the XDI.org Registry Working Group, and the Rebooting the Web of Trust group. It consists of three functions that can be addressed by a combination of blockchain and DHT technology:
>
> * A DID registration function
> * A discovery function that enables looking up a registered DID in the blockchain
> A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
* [All you need to know about sequential UUID generators](https://blog.2ndquadrant.com/sequential-uuid-generators/) Tomas Vondra, 2ndQuadrant
* [DID Primer](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/draft-documents/did-primer.md) Drummond Reed and Manu Sporny and other contributors, RWOT5
* [DID Primer Extended](https://github.com/WebOfTrustInfo/rwot7-fall2018/blob/master/topics-and-advance-readings/did-primer-extended.md)] Drummond Reed and Manu Sporny and other contributors, RWOT7
> While we are committed to providing optionality to our customers, it’s equally important to communicate the selection criteria behind these options so that customers can consider the tradeoffs of underlying DID-methods alongside the problem set they’re solving for.
* [We evaluated 7 DID methods with the W3C DID Rubric! did:btcr, did:sov, did:ion, did:web, did:v1, did:peer, did:ethr](https://iiw.idcommons.net/13D/_We_evaluated_7_DID_methods_with_the_W3C_DID_Rubric!_did:btcr,_did:sov,_did:ion,_did:web,_did:key,_did:peer,_did:ethr)by Walid Fdhila, Markus Sabadello; IDCommons ([video](https://eu01web.zoom.us/rec/play/5wIkMptZK28kj6LFF5NlILMApA-2CwRMw1L7s4aO8wsgFDODJ-pGlbKPh6YA7BEADftL_Uw7sHx6YY2r.KWeBYTIH4BFQmLIv?continueMode%3Dtrue); 5/2021
* [A Rubric for Decentralization of DID Methods](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/decentralized-did-rubric.md) Joe Andrieu, Shannon Appelcline, Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, Oliver Terbu, and Kai Wagner; WebOfTrustInfo rwot9-prague
> One of our main goal is to protect users’ privacy. So people do not use the DID generated from their master key to talk to DAPPs, instead, the WALLET automatically generates an extended DID according to the user’s master DID and the DAPP’s DID and use this extended DID to communicate with the DAPP.
> The Bitcoin Reference DID method (did:btcr) supports DIDs on the public Bitcoin blockchain. The Bitcoin Reference method has minimal design goals: a DID trust anchor based on the Bitcoin blockchain, updates publicly visible and auditable via Bitcoin transactions, and optionally, additional DID Document information referenced in the transaction OP_RETURN data field. No other Personal Identifiable Information (PII) would be placed on the immutable blockchain.
>
> A secondary intent of the BTCR method is to serve as a very conservative, very secure example and some best practices for creating a DID method. The use cases for BTCR are focused on anonymous and pseudo-anonymous identities, web-of-trust style webs of identity, and absolute mimimal personal information disclosure. Other DID methods will likely need to loosen these standards.
>
> Some aspects of the BTCR method will not be practical if inappropriately scaled — for instance, there is a transaction cost to update keys and DDO object, potential UTXO inflation (i.e. one additional unspent output for every BTCR-based identity), and even if segwit isn’t used it could cause blockchain bloat. However, identities using the BTCR method can be a strong as Bitcoin itself -- currently securing billions of dollars of digital value.
> Blockstack's DID method is specified as part of its decentralized naming system. Each name in Blockstack has one or more corresponding DIDs, and each Blockstack DID corresponds to exactly one name -- even if the name was revoked by its owner, expired, or was re-registered to a different owner.
>
> Blockstack is unique among decentralized identity systems in that it is not anchored to a specific blockchain or DLT implementation. The system is designed from the ground up to be portable, and has already been live-migrated from the Namecoin blockchain to the Bitcoin blockchain. The operational ethos of Blockstack is to leverage the must secure blockchain at all times -- that is, the one that is considered hardest to attack.
>
> Blockstack's naming system and its DIDs transcend the underlying blockchain, and will continue to resolve to DID document objects (DDOs) even if the system migrates to a new blockchain in the future.
### [**`did:erc725:`**](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/DID-Method-erc725.md) For Ethereum, by Markus Sabadello, Fabian Vogelsteller, Peter Kolarov
> Decentralized Identifiers (DIDs, see [1]) are designed to be compatible with any distributed ledger or network (called the target system). In the Ethereum community, a pattern known as ERC725 (see [2]) utilizes smart contracts for standard key management functions. We propose a new DID method that allows ERC725 identities to be treated as valid DIDs. One advantage of this DID method over others appears to be the ability to use the full flexibility of Ethereum smart contracts for key management purposes.
> A DID is a simple text string consisting of three parts, the:
> - URI scheme identifier (did)
> - Identifier for the DID method
> - DID method-specific identifier.
>
> **EXAMPLE 1: A simple example of a decentralized identifier (DID)**
> ```
> did:example:123456789abcdefghi
> ```
> The example DID above resolves to a DID document. A DID document contains information associated with the DID, such as ways to cryptographically authenticate the DID controller, as well as services that can be used to interact with the DID subject.
>
> **EXAMPLE 2: Minimal self-managed DID document**
> The Interplanetary Identifiers DID method (did:ipid:) supports DIDs on the public and private Interplanetary File System (IPFS) networks. IPFS is the distributed content addressable permanent web. More specifically, the IPID DID method utilizes the Interplanetary Linked Data (IPLD) suite of tools. The IPID DID method has minimal design goals: a DID trust anchor based on the IPFS and Libp2p protocol. In and of itself, this is not a blockchain solution. However, blockchains and other distributed ledger technologies could be utilized to anchor the artifacts of this DID methods for further enhanced security.
> lifeID is a decentralized, blockchain-based protocol that acts as an open identity provider. The protocol enables the creation and use of self-sovereign identities as well as the issuance of verifiable credentials to those identities. The blockchain-based components of the protocol include smart contracts for storage, revocation, and recovery of keys and credentials. These contracts may be run on any open, permissionless blockchain. The purpose of this protocol is to allow users to transact their identity in a way that minimizes data disclosure, is cryptographically secure, and enables censorship-resistant decentralized identity provisioning and recovery. The purpose of this specification is to describe how lifeID DIDs are created and the technical requirements to operate on the lifeID platform.
> Sovrin is a public ledger designed specifically and only for privacy-preserving self-sovereign identity. The Sovrin Ledger is governed by the international non-profit Sovrin Foundation. As the only public ledger designed exclusively for self-sovereign identity, Sovrin is optimized for DIDs and DID Documents. DIDs are created, stored, and used with verifiable claims. This specification covers how these DIDs are managed. It also describes related features of Sovrin of particular interest to DID owners, guardians, and developers.
> In the Ethereum community, a pattern known as ERC1056 (see [2]) utilizes a smart contract for a lightweight identity management system intended explicitly for off-chain usage.
>
> The described DID method allows any Ethereum smart contract or key pair account to become a valid identity. An identity needs no registration. In the case that key management or additional attributes such as "service endpoints" are required, we deployed ERC1056 smart contracts on:
Mainnet • Ropsten • Rinkeby • Goerli • Kovan • RSK • Alastria • Telsius • ARTIS tau1 • ARTIS sigma1
> Since each Ethereum transaction must be funded, there is a growing trend of on-chain transactions that are authenticated via an externally created signature and not by the actual transaction originator. This allows for 3rd party funding services, or for receivers to pay without any fundamental changes to the underlying Ethereum architecture. These kinds of transactions have to be signed by an actual key pair and thus cannot be used to represent smart contract based Ethereum accounts. ERC1056 proposes a way of a smart contract or regular key pair delegating signing for various purposes to externally managed key pairs. This allows a smart contract to be represented, both on-chain as well as off-chain or in payment channels through temporary or permanent delegates.
* [decentralized-identity/ethr-did-resolver](https://github.com/decentralized-identity/ethr-did-resolver) - DID resolver for Ethereum Addresses with support for key management (and DID reference implementation)
> There are two primary classes of DID-based identifiers in Veres One. The first type of identifier is called a cryptonym-based identifier. This identifier is a SHA-256 hash of a public key. Cryptonym-based identifiers are not required to be registered on the ledger and may be used as unregistered pseudonymous pairwise identifiers. These identifiers may also be registered on the ledger and MUST contain a authentication key with a public key fingerprint equal to the value of the cryptonym-based identifier.
>
> **EXAMPLE 1: A valid Veres One Cryptonym-based Decentralized Identifier**
> The second type of identifier on Veres One is a UUID-based identifier and may be used by entities that want to store metadata on the ledger. These sorts of identifiers are often used, but not limited to, storing and refering to Capabilities and Revocation lists.
>
> **EXAMPLE 2: A valid Veres One UUID-based Decentralized Identifier**
> Commercio.network is a cosmos based sovereign blockchain network, built on the base of cosmos sdk and tendermint state machine replication engine, adopting Proof of Stake as a consensus algorithm.
>
> Commercio.network, aims to be known as "The Documents Blockchain" and is to become "the easiest way for companies to manage their business documents using the blockchain technology".
>
> Commercio.newtork ultimate goal is not just to share documents, but to create a network of trusted organizations, on the base of a web of trust, build on the Decentralized Identifier and Verifiable Credentials standard pillars.
>
> In this document we specify the DID Method for Commercio.network, in comformance to the requirements specified in the DID specification[4] currently published by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, please see DID Primer[6] and DID Specification[4].
> This specification defines how Ontology blockchain[1] stores DIDs and DID documents, and how to do CRUD operations on DID documents. More importantly, this specification confirms to the requirements specified in the DID specification[2] currently published by the W3C Credentials Community Group.
>
> Ontology provides high-performance public blockchains that include a series of complete distributed ledgers and smart contract systems. Ontology blockchain framework supports public blockchain systems and is able to customize different public blockchains for different applications.
> Vivvo is a private ledger designed specifically and only for privacy-preserving self-sovereign identity. The Vivvo Ledger is governed by Vivvo Application Studios. As a private ledger designed exclusively for self-sovereign identity, Vivvo is optimized for DIDs and DID Documents. DIDs are created, stored, and used with verifiable claims. This specification covers how these DIDs are managed. It also describes related features of Vivvo of particular interest to DID owners, guardians, and developers.
### [**`did:aergo:`**](https://github.com/aergoio/aergo-identity/blob/master/doc/did-method-spec.md) For https://www.aergo.io/, by https://www.blocko.io/
> The described DID method allows any Aergo smart contract or key pair account to become a valid identity. An identity needs no registration. In the case that key management or additional attributes such as "service endpoints" are required, we deployed did registry smart contracts on:
> ICON[1,2,3] is a decentralized network that connects various independent communities to enable interoperability between them. ICON DID is a decentralized identifier devised to provide a way to uniquely identify a person, an organization, or a digital device across the communities connected to the ICON network. ICON DID method specification conforms to the DID and the DID Documents Spec[4]. This document describes how ICON blockchain manages the DIDs and the DID documents, and specifies a set of rules for how a DID is created, queried, updated, and revoked.
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. Blockcore supports decentralized identities through the Blockcore Storage feature.
>
> This specification describes how the Blockcore Identity framework aligns with the DID specification and how the Blockcore Universal Resolver works.
>
> This specification conforms to the requirements specified in the DIDs specification currently published by the W3C Credentials Community Group.
>
> The Blockcore Identity registry is a permissionless and borderless runtime for identities.
> InfoWallet is a decentralized network system for Self-Sovereign identity and Verifiable Claims. It can replace a legacy centralized credential system that with trusted blockchain node. In the InfoWallet system, several types of certificates are issued. DID(Decentralized Identifiers) is used as the unique identifier of the certificate. Also DID allows to obtain public key information for secure exchange of information between users.
> A DID that uses this method MUST begin with the following prefix: did:ockam:. Per the DID specification, this prefix MUST be in lowercase. The format of remainder of the DID, after this prefix, is specified below in the section on Method Specific Identifiers.
> Ockam DIDs conform with the Generic DID Scheme described in the DID spec. The format of the ockam-specific-idstring is described below in ABNF:
### [**`did:ala:`**](https://github.com/alastria/alastria-identity/wiki/Alastria-DID-Method-Specification-(Quorum-version)) For Alastria, by Alastria National Blockchain Ecosystem
> - The first one defines the Alastria DID Method Specification, describing the Alastria DID Scheme and the Alastria DID Document.
> - The second part describes the format for Alastria Credentials and Presentations in the current Alastria Red T, based on Quorum.
> - The third part describes the Credentials and Presentation Life Cycle and the Private Credential Multi Hashes (PSM Hashes) used to anchor Credential and Presentation actions ensuring privacy.
>
> The objective of this document is to be aligned with the work on Decentralized IDs (DIDs) and Verifiable Credentials being carried out by the Verifiable Credentials Working Group. The specs are already on the CR (Candidate Recommendation) phase and they may still change. However, its maturity is enough to assume that the changes are going to be minor so it makes sense to align the Alastria DID Method Specification as much as possible to those specifications.
> JLINC is a protocol for sharing data protected by an agreement on the terms under which the data is being shared.
>
> This document specifies methods for creating and editing Decentralized IDs (DIDs) suitable for use with the JLINC protocol. It conforms to the requirements specified in the DID specification currently published by the W3C Credentials Community Group.
> ION is a public, permissionless, Decentralized Identifier (DID) network that implements the blockchain-agnostic Sidetree protocol on top of Bitcoin (as a 'Layer 2' overlay) to support DIDs/DPKI (Decentralized Public Key Infrastructure) at scale.
>
> IMPORTANT NOTE: The majority of ION's code is developed under the blockchain-agnostic Sidetree protocol's repo: [https://github.com/decentralized-identity/sidetree](https://github.com/decentralized-identity/sidetree), which this project uses internally with the code required to run the protocol on Bitcoin, as the ION network.
>
> **Key Points:**
> - ION is public and permissionless - the system is decentralized, no company, organization, or group owns/controls the identifiers and DPKI entries in the system, and no one dictates who can participate.
> - ION doesn't introduce new tokens/coins - Bitcoin is the only unit of value relevant in the operation of the on-chain aspects of the ION network.
> - ION is not a sidechain or consensus system - the network nodes do not require any additional consensus mechanism.
> The Jolocom distributed identity system aims to provide a secure, robust and flexible implementation of the DID and Verifiable Claims specifications published by the W3C and the Decentralised Identity Foundation. It’s core technologies are the Ethereum blockchain and the Interplanetary File System (IPFS).
>
> The Jolocom DID method uses IPFS as a decentralised CAS layer for DID Documents. A deployed smart contract provides a mapping from a DID to an IPFS hash address of the corrosponding DID Document. This enables DID Documents on IPFS to be effectively addressed via their DIDs.
>
> Jolocom DIDs are identifiable by their did:jolo: method string and conform to the [Generic DID Scheme](https://w3c-ccg.github.io/did-spec/#the-generic-did-scheme).
> The method specification provides all the technical considerations, guidelines and recommendations produced for the design and deployment of the DID method implementation. The document is organized in 3 main sections.
>
> - DID Schema. Definitions and conventions used to generate valid identifier instances.
> - DID Document. Considerations on how to generate and use the DID document associated with a given identifier instance.
> - Agent Protocol. Technical specifications detailing how to perform basic network operations, and the risk mitigation mechanisms in place, for tasks such as:
> - Publish a new identifier instance.
> - Update an existing identifier instance.
> - Resolve an existing identifier and retrieve the latest published version of its DID Document.
> Most documentation about decentralized identifiers (DIDs) describes them as identifiers that are rooted in a public source of truth like a blockchain, a database, a distributed filesystem, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases.
>
> However, the vast majority of relationships between people, organizations, and things have simpler requirements. When Alice(Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve their DIDs, only Alice and Bob do. Peer DIDs are perfect in these cases. In many ways, peer DIDs are to public, blockchain-based DIDs what Ethereum Plasma or state channels are to on-chain smart contracts— or what Bitcoin's Lightning Network is to on-chain cryptopayments. They move the bulk of interactions off-chain, but offer options to connect back to a chain-based ecosystem as needed. Peer DIDs create the conditions for people, organizations and things to have full control of their end of the digital relationships they sustain.
* [Peer DIDs — An Off-Ledger DID Implementation](https://academy.affinidi.com/peer-dids-an-off-ledger-did-implementation-5cb6ee6eb168)Affinidi
> - No transaction costs involved
> - Easy to create and maintain
> - Since these DIDs are independent of a central system such as a GDPR controller, they can be scaled as needed
> - Offers the highest levels of privacy as only the parties involved can access the DIDs
> - No uncertainties or external problems since these DIDs are not associated with any particular network
> - No degradation of trust throughout the entire lifecycle.
> - In tune with local-first software philosophies
> - Reduces unnecessary correlation between a verifier and an issuer of a[verifiable credential](https://academy.affinidi.com/what-are-verifiable-credentials-79f1846a7b9).
### [**`did:selfkey:`**](https://github.com/SelfKeyFoundation/selfkey-identity/blob/develop/DIDMethodSpecs.md) For Ethereum, by SelfKey
> The following document defines a DID method for the SelfKey Identity platform. Although this method provides support to the SelfKey ecosystem and its related applications, the underlying DID platform is fully decentralized, and it's designed to serve as a DID layer for other systems that might find it valuable.
>
> The following specifications are subject to change in the future, yet they MUST comply with the latest version of the [generic DID specs](https://w3c-ccg.github.io/did-spec/) as specified by the W3C Credentials Community Group.
>
> The functionality for this method is provided by the DIDLedger smart contract found in [this repository](https://github.com/SelfKeyFoundation/selfkey-identity).
> Metadium is the next-generation identity system powered by blockchain technology. Metadium Decentralized Identifiers is a distributed identifier designed to provide a way for a community connected to the Metadium Ecosystem to uniquely identify an individual, organization, or digital device. The role of a Metadium DID is to provide a service that supports user-authentication and personal information verification.
>
> The Metadium DID method specification conforms to the requirements specified in the DID specification [1], currently published by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, please see the DID Primer [2]
> ```
> meta-did = "did:meta:" + meta-specific-idstring
> meta-specific-idstring = meta-network + ":" + MIN
> meta-network = "mainnet" | "testnet"
> meta-address = 40*HEXDIG
> ```
> The MIN is case-insensitive, but it is recommended to use mixed-case checksum for address encoding (see [3]).
> “Trust Your Supplier” aka “TYS” is actively in development at Chainyard, a leading Blockchain development firm located in RTP North Carolina. The network is undergoing beta testing and will go live in the next couple of months.
>
> The TYS network is a cross industry source of supplier information and identity helping to simplify and accelerate the onboarding and lifecycle management process. TYS is a fit-for-purpose blockchain optimized for sharing supplier credentials in a supply chain environment. TYS DIDs may be used by Suppliers, Buyers, Verifiers, Banks and other organizations to establish identities for verifiable claims made by any party.
>
> TYS is implemented on Hyperledger Fabric, a permissioned blockchain technology under the Linux Foundation’s Hyperledger Project. The “Smart Contract” Functions are written in “Golang” and all client APIs are provided as REST APIs written in “Javascript” running on “NodeJS.
> The Git revision control tool is designed to function in a decentralized peer-to-peer fashion to facilitate collaboration in the frequently-disconnected world. Git uses a directed acyclic graph (DAG) of commits that represent the changes to the folders and files in the repository. Because it uses blockchain-like hash-linking of commits, Git is effectively a blockchain and distributed ledger with the patch review and merge process functioning as the consensus mechanism. This makes it a great tool for tracking the provenance of data inside the repository. Git also records the author and other meta data such as digital signatures with each commit linking identity of committers to each commit. Git repos therefore contain all of the information needed to serve as the single source of truth for the provenance of the data it contains and the identities of the contributors that created it.
* [Git as Authentic Data Creation Tool (a.k.a. what happened to did:git? a.k.a. independently verifiable, secure, developer sovereign, open source software supply chain)](https://iiw.idcommons.net/12A/_Git_as_Authentic_Data_Creation_Tool_(a.k.a._what_happened_to_did:git%253F_a.k.a._independently_verifiable,_secure,_developer_sovereign,_open_source_software_supply_chain))by Dave Huseby
> This session covered the evolution of thinking from the initiation of did:git at IIW April 2019 up until now. I recently chose to deprecate the did:git proposal in lieu of a new project to update Git to use provenance logs for identifier management in Git repos. I recently wrote an [article describing the proposal](https://dwhuseby.medium.com/universal-cryptographic-signing-protocol-for-git-42e7741b8773), and the [current proposal is here](https://github.com/TrustFrame/git-cryptography-protocol)
### [**`did:tangle:`**](https://github.com/TangleID/TangleID/blob/develop/did-method-spec.md) For IOTA Tangle, by BiiLabs Co., Ltd.
> IOTA is a public distributed ledger that utilizes an invention called the Tangle at its core, address scalability issues and having no transaction fee, that encourages adoption of the technology in the industry. TangleID is intended to implement DIDs and DID Documents.
>
> TangleID also optimizes MAM for key management and related features across the Tangle. Masked Authenticated Messaging (MAM) is a data communication protocol which adds functionality to broadcast and access data streams over the Tangle which adds integrity to these message streams. The owner of seed in MAM is able to create a channel structure like above to transfer the messages. TangleID stores and manages corresponding DID Documents on the MAM channels, and use the initial channel id as the DID’s idstring, each revision of the DID document is recorded on the message of the endpoint afterward.
> The Emtrust DID method utilizes Hyperledger fabric as the DLT implementation, having an identity channel which is shared among the identity nodes with participating organizations. The DID document along with metadata of third party endorsements resides on ledger and the private information of users are kept on the mobile or persona devices which never leaves the device. The Interaction of DID and blockchain ledger happens via the API servers hosted by any participating organizations.
> <32 byte hexadecimal string> corresponds to keccak256 and the hash value of Ethereum address connected by random numbers generated in the DID contract.
>
> DID is registered in the contract and controlled by a single Ethereum address, which is set by default to the address where the createDID method was originally called. Then, this address can transfer control to a different address, or update/delete the corresponding DID in the contract.
> The DID ledger is implemented as a simple layer of persistent identity registration on the Ethereum blockchain network. Meanwhile it can be extended to contain other data and functions. Scalability is achieved by using an identity contract as a controller for DID on the ledger. In particular, ERC725 combined with private key management contract, for example, ERC734 is expected to involve additional features with common conditions (such as defines service endpoint, private key rotation, delegation and licensing, etc.). At the meantime, it gives the permit of exploiting other standards, and even allows the owner of DID to transforms contract implementation to another without losing its identifier.
> Weelink DID is a new blockchain-based authentication method that follows all the requirements of W3C. Based on Weelink Wallet, our method provides a series of APIs and services for a fast and secure authentication process.
>
> The rapid development of Internet has provided unparalled convenience to the public, yet it is also inevitably bringing some potential problems. One of them is the leaking of private information that comes with traditional authentication systems. Taking advantage of blockchain’s decentralization and security characteristics, we thus propose our secure authentication method.
### [**`did:pistis:`**](https://github.com/uino95/ssi/blob/consensys/dashboard/server/pistis/pistis-did-resolver/README.md) For Ethereum, by Andrea Taglia, Matteo Sinico
> This specification defines how Pistis deals with DID and DID Documents and how it interacts with the Ethereum blockchain. Also CRUD operations on DID documents are described. This specification confirms to the requirements specified in the DID specification[1] currently published by the W3C Credentials Community Group.
>
> Pistis is a credential management system based on the Ethereum blockchain. It provides a set of novel smart contracts to handle efficient multi signature operations, delegates management, permissioned access to extensible services based upon the Decentralized IDentifier specification.
> All transactions on Holochain are signed by a user's key. Therefore, by learning a holo DID, an observer/attacker is able to link the user's Holochain activities with potential DID-based applications such as DID Auth or Verifiable Credentials. Users should be aware that he/she can publish their own data associated with their public key on a specific Holochain network.
> The target system of the Web DID method is the web host that the domain name described by the DID resolves to when queried through the Domain Name System (DNS).
> The method specific identifier MUST match the common name used in the SSL/TLS certificate, and it MUST NOT include IP addresses or port numbers. Directories and subdirectories MAY optionally be included, delimited by colons rather than slashes.
> Our DID design allows each manufacture or entity to have its own namespace, which stores and manages DIDs through a self-managed DID contract. A self-managed contract could have customized business logic to adapt the application's needs but has to implement the SelfManagedDID interface, defined as follows:
> ```
> interface SelfManagedDID {
> function createDID(string id, bytes32 hash, string uri) public returns (string);
> function deleteDID(string did) public;
> function updateHash(string did, bytes32 hash) public;
> function updateURI(string did, string uri) public;
> function getHash(string did) public view returns (bytes32);
> function getURI(string did) public view returns (string);
> Vaultie DID method uses IPFS as a decentralised storage for DID Documents. An Ethereum transaction, that does not require any additional Smart Contracts, provides a mapping from a DID to an IPFS hash address of the corrosponding DID Document. This enables DID Documents on IPFS to be effectively addressed via their DIDs. While this method requires additional step in order to lookup DID Document, the method is much more cost effective than using Smart Contracts and Ethereum's expensive storage.
> The MOAC DID method uses MOAC blockchain as a decentralized storage layer for DID Documents. A deployed smart-contract provides a mapping from a DID to an MOAC blockchain hash address of the corrosponding DID Document. This enables DID Documents on MOAC blockchain to be effectively addressed via their DIDs.
> OmniOne is a decentralized network system for Self-Sovereign identity and Verifiable Claims. It can replace a legacy centralized credential system that with trusted blockchain node. In the OmniOne system, several types of certificates are issued. DID(Decentralized Identifiers) is used as the unique identifier of the certificate. Also DID allows to obtain public key information for secure exchange of information between users.
> Workday offers a decentralized Credentialing Platform with a Blockchain based trust layer. A key component of the platform is the WayTo by Workday mobile app which allows the user to store verifiable identity documents, encrypted using their own personal encryption key, which is managed in the Trusted Execution Environment (TEE) of their mobile device. The mobile app can hold official documents, training certifications, verified accomplishments and other credentials. The user can choose what to share, and with whom to share it with. Users of the Workday Credentialing Platform will have a DID and a corresponding DID Document on a permissioned ledger, which credential verifiers can use to validate users’ cryptographic signatures, included in their credentials.
> The system aims to provide secure authentication and various payment services based on the DID and Verifiable Claims specificiatons published by the W3C and the Decentralised Identity Foundation. VP DID is a decentralized identifier devised to provide a way to uniquely identify a person, an organization. VP DID document contains information for providing various payment methods among network participants in a decentralized way. This specification defines how VP blockchain stores DIDs and DID documents, and how to do CRUD operations on DID documents.
> The namestring that shall identify this DID method is: vp. A DID that uses this method MUST begin with the following prefix: did:vp. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
> Building a decentralized ID system based on blockchain and consortium chains will have almost equal control over the system and enhance cooperation intentions.
Blockchain asymmetric encryption technology combines public and private keys to ensure the authenticity and reliability of ID and certification.
Form a richer user portrait, with multiple tags (VIP authentication, privilege authentication, asset authentication...) and one ID.
> ```
> did:ccp:1FsbKR6UpV6GW8o8szccdxXkquzTg2VZLL
> ```
> Where `<method-specific-id>` = `base58(ripemd160(sha256(<Base DID Document>)))` (Refer to Bitcoin, use double hash).
> The system provides secure credential management services based on the DID and Verifiable Claims specifications published by the W3C and the Decentralised Identity Foundation. JNCTN DID method enables an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers with self soverign identity services. JNCTN DID document contains information for accessing JNCTN DID network methods, how JNCTN stores DIDs and DID documents, and how to do CRUD operations on JNCTN DID documents. This specification is intended to be conformant with the DID Specification at https://w3c-ccg.github.io/did-spec/.
> The namestring that shall identify this DID method is: jnctn. A DID that uses this method MUST begin with the following prefix: did:jnctn. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
### [**`did:evan:`**](https://github.com/evannetwork/evan.network-DID-method-specification/blob/master/evan_did_method_spec.md) For evan.network, by evan GmbH
> evan.network is a blockchain for digitalization and automation of business transactions. The network members create digital twins for their machines and products and develop standards for cross-company transactions. The open technology allows integration into existing business models. evan.network guarantees 100% reliable and permanently secured information.
>
> This document specifies the DID method for evan.network, including how an evan.network DID is assembled, several sample documents, details about CRUD operations on DID, as well as security and privacy considerations, as required by the W3C DID specification. For more information regarding DID, please refer to the W3C DID working draft.
### [**`did:elastos:`**](https://github.com/elastos/Elastos.DID.Method/blob/master/DID/Elastos-DID-Method-Specification_en.md) For Elastos ID Sidechain, by Elastos Foundation
> DID is completely under the control of the DID subject, without reliance on any centralized registration body, commercial identity provider, or organization issuing certificates. The DID is described in the DID documents. Each DID document includes at least two items: encryption materials and verification methods. The encryption materials integrated with the verification methods provides a set of identify verification mechanisms (such as a public key, anonymous biological identification agreement, etc.), with other optional parts that can be used according to the needs of the application and of the user.
> There are two goals for the creation of this specification. The first is to define an internal Elastos system standard for the DID documents description format and a basic DID property set, allowing Elastos ecosystem apps to understand the basic digital identity information defined in the standard set, thereby achieving standardization of digital identities in the Elastos ecosystem. The secondary goal is to define a set of general operation methods that can be used for any dApp to reference to the Elastos DID service.
### [**`did:kilt:`**](https://github.com/KILTprotocol/kilt-did-driver/blob/master/DID%20Method%20Specification.md) For KILT Blockchain, by BOTLabs GmbH
> KILT DIDs are stored on KILT Protocol's blockchain that is public and by definition decentralized. The KILT Blockchain runs in a proof-of-authority manner and will become permissionless, see `§ Status of this document` in this specification document.
>
> KILT Blockchain nodes implement a DID module to create, store, query and manage DIDs in the form of on-chain DID items. A DID item is a mapping between the DID owner's public address and its public signature key `sign_key`, its public encryption key `box_key`, and an optional location for the associated DID Document `doc_ref`:
> Element is an implementation of the Sidetree protocol that uses the Ethereum blockchain as the ledger layer and IPFS as the Content-addressable storage layer
> A DID that uses this method MUST begin with the following prefix: did:elem. Per the DID specification, this string MUST be in lowercase.
>
> An additional optional network specific identifier may be added as such
> By default, if the network specific identifier is not present, then the default is ropsten. The default may change in the future once mainnet is supported.
>
> The remainder of a DID after the prefix, called the did unique suffix, MUST be SHA256 hash of the encoded create payload (see below)
> The `github` method is meant to make working with DIDs very simple at the cost of trusting Github.com for assisting in resolving DID Documents.
>
> Many developers are familar with Github, and its 2 supported public key cryptosystems, GPG and SSH.
>
> Linked Data Signatures are difficult to work with when operating a server or running a local node of some distributed system / blockchain is a requirement.
>
> The objective of GitHub DID is to encourage contribution to the DID Spec and Linked Data Signatures, and allow rapid development of extensions to these without requiring the use of slow, or complicated more trustless infrastructure, such as blockchains or other distributed systems.
> BID provides distributed identifiers and blockchain-based digital identity services for people, enterprises, devices and digital objects. It aims to build a decentralized, data-secure, privacy-protected and flexible identifier system that addresses trusted connections among people, enterprises, devices and digital objects，enabling the vision of the Internet of Things and trust ingress with everything.
>
> BID is built on decentralized identification protocols and equipped with characters like decentralization, self-management, privacy protection, security and ease of use. Each BID links to one BIF DID Description Object (DDO).
> Description of each field in the Base DID Document example (★ required fields, others are optional fields):
>
> * ★ `context` A single value or an array, specifying the syntax standard that the DID Document format complies with.
> * `controller` Single value or array, other owners of DID Document. You can specify other DIDs to manage the file, and the permissions of other DIDs will be set in the corresponding operations authentication, updation, deletion, and recovery later. The default is controlled by the DID in the DID Document corresponding to the Base DID Document.
> * ★ `publicKey` A single value or an array that controls the public key information corresponding to the private key of the DID Document.
> * ★ `id` The ID of the public key, `#keys-<num>` expressed in a unified way, incremented `<num>` from the `1` beginning.
> * ★ `type` The algorithm of public key generation is unified with the chain,
> * `controller` The owner of the public key `controller` corresponds to the one in the previous level. The format is `<DID>#keys-<num>`. The default situation is controlled by the document DID. `<DID>` The value on the stage controller, a `#keys-<num>` is `<DID>` a corresponding public key `id`.
> * `publicKeyHex` Hexadecimal information of the public key. When the above controller is the default, this field is **required**.
> * ★ `authentication` Specify `publicKey` which fields can be used for authentication.
> * `updation` Specify `publicKey` which fields can be used for DID Document **update** operations, such as updating information such as pubkey or service.
> * `deletion` Specify `publicKey` which fields can be used for DID Document **delete** operation.
> * `recovery` Specify `publicKey` which fields can be used for DID Document **recovery** operations.
### [**`did:echo:`**](https://github.com/echoprotocol/uni-resolver-driver-did-echo/blob/master/echo_did_specifications.md) For Echo, by Echo Technological Solutions LLC
> We propose a new DID method that allows special objects in ECHO network to be treated as valid DIDs.
> Method Specific Identifier
> The method specific identifier is composed of network type and id of object at ECHO network.
>
> Network type can be '0' for mainnet, '1' for testnet and '2' for devnet. Next goes triplet of numbers devided by points: id of object at ECHO network.
>
> Note: if it's not one of this networks, value will be '255'.
### [**`did:trustbloc:`**](https://github.com/trustbloc/trustbloc-did-method/blob/master/docs/spec/trustbloc-did-method.md) For Hyperledger Fabric, by SecureKey
> The did:trustbloc DID method allows groups of independent entities to share custody of a DID registry consisting of a Sidetree implementation over a permissioned ledger. For more information on Sidetree, please refer to the Sidetree protocol specification.
>
> Independent stakeholders wishing to transact with one another using DIDs can come together to form a consortium to manage their shared custody of a ledger.
>
> This spec defines a discovery service. The discovery service provided by the TrustBloc DID Method allows a client to verify that a consortium is endorsed by its constituent stakeholders, verify that the configuration files of each stakeholder (which includes a list of Sidetree endpoints) are signed by the respective stakeholders, and use the provided Sidetree endpoints to perform Sidetree DID operations.
> The system aims to provide secure authentication and various health services based on the SAN blockchain and DID & Verifiable Credential Specifications published by the W3C.
> The namestring that shall identify this DID method is: san
> Gataca’s platform is based on a mobile identity portfolio, a set of APIs, and controllers for multiple blockchain networks.
>
> Gataca is agnostic to the blockchain network. We adapt our infrastructure to the third party’s preferred ledger. Gataca currently supports the public network Ethereum and private networks based on Hyperledger Fabric, Hyperledger Besu or Quorum. Other networks may be added as requested.
>
> This document provides the DID method specs for how our DID schema is implemented on the Ethereum network.
>
> The simple structure links an object to a DID with states and public keys. Users do not need privileges to read the information on the blockchain but do need them to write. Gataca is the unique user that can modify the smart contract.
> This proposal contains the interoperability specifications for products creating, reading (resolving) updating and deactivating Decentralized Identifiers on top of the Factom Protocol. This specification is not about other products wanting to use DIDs for their specific purpose, like signing or voting. This document describes the low level data structures and rules for DIDs, DID documents, resolution and registration on Factom itself.
>
> Decentralized Identifiers are a cross ledger solution to support self sovereign identities. The Factom Protocol is ideally suited to store DIDs. This specification is the first step in creating a single specification for maximum interoperability with regards to identities across products and solutions on top of the Factom Protocol.
> The <20 byte hexadecimal string> corresponds to an Ethereum address in the current implementation, but maybe abstracted to different identfiers when implemented on different networks.
>
> The <network> string corresponds to human readable form of an distributed ledger capable of running Ethereum smart contracts, including the following:
> DIDs are registered in the DID Registry on-chain, and have a controller and a subject, expressed in the form of Ethereum addresses. The DID controller may or may not be the subject itself. Multiple controllers can be implemented through proxy smart contracts.
### [**`did:hedera:`**](https://github.com/hashgraph/did-method/blob/master/did-method-specification.md) For Hedera Hashgraph, by Hedera Hashgraph, Swisscom Blockchain AG
> This document defines a binding of the Decentralized Identifier architecture to Hedera Hashgraph - specifically how to use the Hedera File Service to record membership in 'business application networks' (appnets) and how to use the Hedera Consensus Service (HCS) for CRUD mechanisms on DID documents stored in such business application network. An business application network is a network of computers that store some set of business data (such as DID Documents) in a shared state, and rely on the Hedera mainnet for timestamping and ordering the transactions that cause that business application network state to change. An business application network could be exclusively dedicated to managing DID Documents and other identity artifacts in its state, or it could itself be multi-purpose. For instance, a Supply Chain could establish an business application network and, in addition to using HCS for tracking the location of shipments, use the DID method defined here to manage the identities of the associated companies, employees, and IoT devices. The HCS model is designed to off load from the Hedera mainnet node the burden of disk writes and long term storage and so allow those nodes to be optimized for high throughput ordering of transactions.
### [**`did:sirius:`**](https://gitlab.com/proximax-enterprise/siriusid/sirius-id-specs/-/blob/master/docs/did-method-spec.md) For ProximaX Sirius Chain, by ProximaX Enterprise, Proximax Inc.
> ProximaX SiriusID is intended to implement `did:sirius` and its DID Document.
> A DID that uses this method MUST begin with the following prefix: did:sirius. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is specified below.
> The SiriusID DID schema is defined by the following:
### [**`did:dock:`**](https://github.com/docknetwork/dock-did-driver/blob/master/Dock%20DID%20method%20specification.md) For Dock, by https://www.dock.io/
> Currently, three public key and signing algorithms are supported for authentication.
> - Schnorr signatures with Sr25519. The public key is 32 bytes and signature is 64 bytes in size. These are supported by Substrate and Polkadot.
> - EdDSA signatures with Ed25519 curve. The public key is 32 bytes and signature is 64 bytes in size.
> - ECDSA signatures with secp256k1 curve. Compressed public keys are used, hence the public key is 33 bytes in size. Signature is 65 bytes in size.
> Dock is currently running as a proof of authority network but will evolve into a proof of stake chain. DIDs can be created by anyone holding Dock tokens but the creator of the DID is not necessarily the owner of the DID and thus cannot manage (update, remove) them. DIDs are managed using their corresponding private keys and these keys are independent of keys controlling the Dock tokens spent while creating the DID.
>
> The chain does not store the full DID document but only the DID, the corresponding keys and controllers and block number for the last update and this block number changes with each update to the DID. This is needed for replay protection. Dock's client SDK retrieves those details and constructs the full DID document.
>
> Currently, Dock supports registering a new DID with only one public key on chain. The key can be rotated by providing a signed message from the current key. The DID can be removed by providing a signed message from the current key. In future, multiple keys for authentication and authorization and other relevant W3C compliant features will be supported.
> Twitter is a highly used and influential social media network that lacks decentralization and higher levels of trust (i.e. signed messages). The `did:twit` specification makes an attempt to increase trust in Twitter interactions.
>
> The method is similar to [did:key](https://w3c-ccg.github.io/did-method-key) in the sense that it is uses a `did` to wrap a single public key.
>
> The objective of Twitter DID, similar to that of the [GitHub DID Method](https://github.com/decentralized-identity/github-did), is to encourage use of the [DID Spec](https://w3c-ccg.github.io/did-spec/), by lowering the barrier to entry for use of the technology, and promote higher trust interactions.
> NEAR uses readable account identifiers instead of a hash of a public key, and the accounts have some DID features, but not all. We have developed this specification to define a new DID method for hosting DIDs on the NEAR blockchain, also referred to as NEAR DID, and facilitate developers to work with related contracts.
### [**`did:vaa:`**](https://github.com/caict-develop-zhangbo/vaa-method/blob/master/README.md) For bif, by China Academy of Information and Communications Technology (CAICT)
> Blockchain Identifier Infrastructure (BIF) is a permissioned public blockchain aiming for creating a distributed trust management framework typical for internet ID service, and the BIF blockchain (http://bidspace.cn/) is governed by China Academy of Information and Communications Technology (CAICT). CAICT is also the official issuing agency with Issuing Agency Code (IAC)——"VAA", given by ISO/IEC 15459. The IAC indicates an authorized qualification of distributing identifiers with own allocation rules.
>
> As the "VAA" means a self-defined rule for internet identifiers, these letters could be literal used as a DID method name conformant with W3C DID specification. The VAA method is created not only to define a random identifier generation rules, but ultimately to create smart contracts, which support different identifiers format.
> The `bba` DID method aims to enable the Ardor blockchain to act as a DPKI within the SSI ecosystem. It runs on the independent IGNIS child chain and utilizes Ardors Account Properties feature to manage DIDs and corresponding DID controllers. The Account Properties feature provides the possibility to tag an account with a small amount of data (160 characters). A DID controller is always represented in form of an Ardor account and is by default separated from the public keys (if present) embedded in a DID document. Think of a master key controlling the DID operations create, update and deactivate. A DID controller always corresponds to exactly one Ardor account, whereas one Ardor account can control multiple DIDs.
>
> DID and DID document handling is decoupled so that multiple DID document storages can be defined and integrated to store DID document templates (DID documents without a DID reference). In its current state, the `bba` DID method defines only one storage type (Ardor Cloud Storage).
>
> In the following, `bba` DID method compliant account properties are called DID attestations. An account property is `bba` DID method compliant if it aligns to the data model described in the DID Attestation Data Fields section and is self-set. A self-set account property is a property in which sender and receiver accounts are identical.
> Distributed ledger technologies (DLT, blockchain) are mostly used by cryptocurrencies, but their event ordering and decentralized consensus algorithms are useful for general purpose. Morpheus needs DLT for safe ordering DID updates and querying the historical state of a DID Document at any given point of time for signature validation. The main benefit of DLTs is that many parties with opposing interests run the infrastructure, therefore it is almost impossible to unilaterally control changes to the history and state of the ledger.
>
> Morpheus currently uses the Hydra blockchain, a dPoS ledger built as an Ark bridgechain and customized with DID-related transactions. Morpheus has a ledger-agnostic design, thus could operate with other ledgers as well.
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This ETHO DID method specification describes a new DID method, that is, ETHO DID and defines how Ethereum blockchain stores ETHO DIDs and their corresponding DID documents, and how to do CRUD operations on ETHO DID documents.
### [**`did:bnb:`**](https://github.com/ontology-tech/DID-method-specs/blob/master/did-bnb/DID-Method-bnb.md) For Binance Smart Chain, by Ontology Foundation
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Binance DID method specification describes a new DID method, that is, Binance DID and defines how Binance Smart Chain stores Binance DIDs and their corresponding DID documents, and how to do CRUD operations on Binance DID documents.
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Celo DID method specification describes a new DID method, that is, Celo DID and defines how Celo blockchain stores Celo DIDs and their corresponding DID documents, and how to do CRUD operations on Celo DID documents.
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This Klaytn DID method specification describes a new DID method, that is, Klaytn DID and defines how Klaytn blockchain stores Klaytn DIDs and their corresponding DID documents, and how to do CRUD operations on Klaytn DID documents.
> Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This TRON DID method specification describes a new DID method, that is, TRON DID and defines how TRON blockchain stores TRON DIDs and their corresponding DID documents, and how to do CRUD operations on TRON DID documents.
### [**`did:schema:`**](https://github.com/51nodes/schema-registry-did-method/blob/master/README.md) For Multiple storage networks, currently public IPFS and evan.network IPFS, by 51nodes GmbH
> The Schema Registry DID Method aims to provide unique and universal identification for schemas in multiple formats hosted on multiple storage mechanisms or networks.
>
> This first version will focus on JSON Schema and XML Schema Definition/XSD schemas stored using the IPFS (InterPlanetary File System) protocol, but the DID method and concept is open for contributions and extensions regarding further schema formats and storage/network options.
### [**`did:key:`**](https://w3c-ccg.github.io/did-method-key/) For Ledger independent DID method based on public/private key pairs, by Rick Astley (thank you for your inspiration), Manu Sporny, Dmitri Zagidulin, Dave Longley, Orie Steele
> While DLT-based DID Methods have great decentralization characteristics, and some of the more centralized DID Methods provide strong system control guarantees, the general approaches tend to be expensive to setup and operate. Some use cases requiring DIDs do not need the guarantees provided by these heavy-weight systems. For example, a DID that will only be used for a single, ephemeral interaction might not need to be registered, updated, or deactivated. It is for this class of use cases that the did:key method exists.
> The format for the did:key method conforms to the [DID-CORE] specification and is simple. It consists of the did:key prefix, followed by a Multibase [MULTIBASE] base58-btc encoded value that is a concatenation of the Multicodec [MULTICODEC] identifier for the public key type and the raw bytes associated with the public key format.
> Self-Sovereign Identity (SSI) allows people to manage their digital identities, proving who they are without a middleman, by anchoring DIDs on blockchain platforms as a shared root of trust. However, most blockchains still can't provide decentralized identity at scale. By implementing the Tyron SSI Protocol, tyronZIL aims to solve this issue and enable user-controlled digital identities.
>
> The word Tyron derives from the Greek turannos that means sovereign, and Tyron's purpose is to give people sovereignty over their data.
### [**`did:corda:`**](https://htmlpreview.github.io/?https://github.com/persistentsystems/corda-did-method/blob/master/corda_did_method.html) For Corda, by Nitesh Solanki,Moritz Platt,Pranav Kirtani
> To understand the environment in which the Corda DID method operates, the permissioned nature of a Corda network and the point-to-point approach to data replication must be taken into account. While parties in permissionless blockchains remain anonymous and can join and leave at will, any Corda network utilizes a standard PKIX infrastructure for linking public keys to identities [corda-whitepaper]. As such, individually deployed entities in the network – nodes – have a strong notion of identity. This concept is instrumental in network communication. Similarly, the data-replication model implemented in Corda is different to that of a conventional public blockchain, which makes all in-ledger data visible to all network participants. In Corda, data are distributed to a configurable subset of network members only.
> The Corda DID method operates in an environment where multiple nodes form a consortium in order to replicate decentralized identity data (cf. figure 1). These consortium nodes replicate decentralized identifier documents to form a network-wide and, ultimately, consistent view of the unity of decentralized identifiers, using the Corda DID method.
### [**`did:uns:`**](https://github.com/unik-name/did-method-spec/blob/main/did-uns/UNS-DID-Specification.md) For https://docs.uns.network/, by https://www.spacelephant.org/
> The uns DID method provides support for DIDs on the uns.network blockchain. More specifically, it associates a DID to every address in the ledger. This method is very minimalistic in the sense that it produces DID Document (DDoc) with minimal information: a DID and its associated public key. Furthermore, once a uns-did is created, it cannot be updated.
>
> The goal of this method is to work in tandem with other, more complex DID methods based on the same blockchain. Uns.network is dedicated to the management of Non Fungible Tokens (NFT). The first type of NFT that it supports is [@uniknames](https://docs.unikname.com/), human-readable identifiers. Just like any other tokens, @uniknames can be bought or exchanged, but they can also be linked to public properties the owner wishes to advertise, or used to connect to compliant websites in a private and secure fashion, among other things. The `unik` DID method associates a DID to these NFT tokens, using uns-did as controllers.
>
> Identifiers are only the first use case for uns.network NFTs. Other use cases are likely to require their own DID method based on uns DIDs.
> Panacea is a public blockchain built by MediBloc to reinvent the healthcare experience. Panacea also supports DID operations. DIDs are created and stored in the Panacea, and they are used with verifiable credentials.
> DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption. We propose using a new DID method that allows them to bootstrap trust using a Tor Hidden Service's existing reputation.\
> we'd like to review more with our community how close we want to keepdid:oniontodid:web, and if we want to incorporate some elements ofdid:peeror KERI or to leverage services like Open Time Stamps.
* [Discussion of NFT and music projects, NFT:DID for turning NFT's into identities, and critical updates en route to mainnet.](https://www.youtube.com/watch?v%3DJfvRLhz6OpY)Ceramic Community Call
> you can go to [ceramicnetwork/nft-did-resolver](https://github.com/ceramicnetwork/nft-did-resolver)on github to see the prototype
> so this is the minimal implementation that allows you to verify signatures of the most recent owner of the nft did as like being valid
* [The EOSIO DID method specification](https://www.gimly.io/blog/the-eosio-did-method-specification)
> We have been working with the [Decentralised Identity Foundation](https://identity.foundation)to shape this specification, and also want to thank the [W3C Credentials Community Group](https://www.w3.org/community/credentials/)for their support in the creation of the [Verifiable Condition](https://github.com/Gimly-Blockchain/verifiable-conditions)type, a necessary component to create the EOSIO DID document to represent EOSIO account permissions.
* [did:did - DID Identity DID (DID) DID method](https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0026.html)
> Spruce announces did:did, a DID method based on Decentralized Identifiers (DIDs). We hope the community will find this useful to help increase adoption and interoperability of Decentralized Identity technology.
> Clarification, a few week ago we shared about the [DID:DID](https://did-did.spruceid.com/)method. [April Fools Joke](https://en.wikipedia.org/wiki/April_Fools%2527_Day_RFC)!!! Here’s yet another DID method in the series.
>
> did:un-did is a DID method that enables using any valid Decentralized Identifier (DID) as a did:un-did DID, but more importantly it un-does the did that did:did did method performs.
* [DogeCoin DID Method by Spruce Systems](https://github.com/spruceid/did-doge)
> - Such Decentralization: Dogecoin is a public, permissionless blockchain favored by Shiba Inus worldwide, making it suitable for this purpose.
> - Much Identity: Since shibes are unique in different and special ways, this specification provides the means to assign each one their very own ShibeID.
> - Wow Blockchains: Dogecoin has proven again and again its resiliency in the face of adversity, proving that it is the ultimate host to such a primitive.
* [Decentralized Identity with the Tezos DID Method](https://sprucesystems.medium.com/decentralized-identity-with-the-tezos-did-method-d9cf6676dd64)
* [UNISOT DID approved by W3C](https://unisot.com/unisot-did-approved-by-w3c/) Unisot [gitlab](https://gitlab.com/unisot-did)
> We are proud to have UNISOT ID (did:unisot) listed at the Decentralized Identity Foundation (DIF). As part of our commitment to open technologies and global interoperability we have presented our DID schema (did:unisot) to the Decentralized Identity Foundation (DIF) and supplied a driver for their Universal DID Resolver which can be accessed at:[https://resolver.identity.foundation/](https://resolver.identity.foundation/). With this anyone can resolve a UNISOT DID Document in a trusted and easy way.
* [SecureKey’s New Ledger-Agnostic did:orb](https://securekey.com/securekeys-new-ledger-agnostic-solution-orb-helps-solve-decentralized-identifier-challenges/)
did:orb that decouples DIDs from ledgers while maintaining trust and security. SecureKey is leveraging standard and open-source peer-to-peer protocols like ActivityPub, data structures like verifiable credentials content-addressed storage like IPFS, and distributed trust services like the Google Trillian project to build a peer-to-peer trust network.
## Critique
* [Don’t use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh no he DIDn’t)](https://dwhuseby.medium.com/dont-use-dids-58759823378c) by Dave Huseby ([video](https://eu01web.zoom.us/rec/play/4_ZLV8uot0hFQgRZsoILvdnn879oGEmrXsPXsCcvf4GsDPjWLQAxKjrZFiF0AxQe_MYb1_oeQa9HsRY.8KTaTYyrhu2Q-kJ_?continueMode%3Dtrue))
> Joe came and fervently disagreed with my assertions. Lots of people had reasonable counter arguments. My main arguments are 1. DID Documents don't have history when old keys are always relevant and 2. having 94 different DID methods that aren't compatible nor replaceable and don't function the same way is a HUGE problem.
>
> There was no conclusion other than Sam Smith and I came to the conclusion that we have more in common than we thought.
* [Don’t use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh no he DIDn’t)](https://iiw.idcommons.net/10A/_Don%2527t_use_DIDs,_DIDs,_nor_DIDs:_Change_My_Mind_(a.k.a._Oh_no_he_DIDn%2527t))by Dave Huseby
> This session was to talk about the topics I put in a recent article that created a huge fire in our community where I lay out the case for completely abandoning the W3C DID standards.
* [Don’t Use DIDs: Political Solutions Never Solve Technological Problems](https://dwhuseby.medium.com/dont-use-dids-58759823378c)DW Husebey
A large set of impact investor, international donor, and government anti-poverty policy is based on the notion that for-profit companies can be induced to serve the poor with life changing services like banking or schooling but the limits of the for profit model are not always taken into account
* [godiddy.com - Universal DID Services](https://iiw.idcommons.net/2C/_godiddy.com_-_Universal_DID_Services)by Markus Sabadello [[Documentation](https://docs.godiddy.com/)][[API Reference](https://api.godiddy.com/)]
> Basic functions are creating, resolving, updating, and deactivating DIDs across multiple DID methods and networks. Advanced functions include key management, search, transfer of DIDs, lookup of historical DID document versions, notification of DID-related events, and more.
* [Standard Interfaces for DID Create/Update/Deactivate](https://iiw.idcommons.net/3C/_Standard_Interfaces_for_DID_Create/Update/Deactivate)by Markus Sabadello
> - There is an attempt to specify abstract interfaces if you want to Create/Update/Deactivate a did that could be implemented for all did methods.
> - The idea of this specification is to provide a standard with the same assumptions as with resolution. It should be in an abstract level, meaning it should specify the inputs and outputs of creating/updating/deactivating a did but not how it should be implemented.
