DID Methods - Various

Main

• did:directory From: Legendary Requirements Type: Directory

DID methods are the magic ingredient that gives DIDs their flexibility. Before creating any specific DID, you first choose a DID method, which determines how you perform the create, read, update, and deactivate operations on a DID of that method.

Once created, each DID includes the name of its method in the identifier itself, so that when you use the DID, others know how to retrieve the associated DID Document that contains the cryptographic material for secure interactions.

Different DID methods use different underlying mechanisms with different performance, security, and privacy tradeoffs.

• DID Specification Registries From: DIDWG Related: Decentralized Identifiers Type: Registry Date: 2023-05-14

This table summarizes the DID method specifications currently in development. The links will be updated as subsequent Implementer’s Drafts are produced.

• DID:Customer From: Transmute By: Margo Johnson Related: Decentralized Identifiers Type: Post Date: 2020-10-30

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.

• A Rubric for Decentralization of DID Methods From: WebOfTrustInfo By: Joe Andrieu, Shannon Appelcline, Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, Oliver Terbu, Kai Wagner Related: Decentralized Identifiers Type: Paper Date: 2019-09-06 Event: rwot9-prague

The communities behind Decentralized Identifiers (DIDs) bring together a diverse group of contributors, who have decidedly different notions of exactly what “decentralization” means. For some, the notion of a DID anchored to DNS is anathema, for others, DIDs that cannot be publicly verified are problematic. This debate about decentralization is a continuation of a similar, ongoing argument in cryptocurrency circles: the question of whether or not bitcoin or ethereum is more decentralized is a nearly endless source of argument. Rather than attempting to resolve this potentially unresolvable question, we propose a rubric — which is a scoring guide used to evaluate performance, a product, or a project — that teaches how to evaluate a given DID method according to one’s own requirements. Our goal is to develop a guide that minimizes judgment and bias. Rather than advocating particular solutions, the rubric presents a series of criteria which an evaluator can apply to any DID method based on their particular use cases. We also avoid reducing the evaluation to a single number because the criteria tend to be multidimensional and many of the options are not necessarily good or bad: it is the obligation of the evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs. Finally, this rubric allows evaluating aspects of decentralization of a DID method, but it is not exhaustive, and does not cover other issues that may affect selection or adoption of a particular method, such as privacy or efficiency.

• DID Method Rubric v1.0 From: IDCommons Related: Decentralized Identifiers Type: Guidance Date: 2022-01-11 Event: IIW

This rubric presents a set of criteria which an Evaluator can apply to any DID Method based on the use cases most relevant to them. We avoid reducing the Evaluation to a single number because the criteria tend to be multidimensional and many of the possible responses are not necessarily good or bad. It is up to the Evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs.

• DID Methods Evaluation Report From: IDCommons By: Walid Fdhila, Markus Sabadello Related: did:btcr, did:sov, did:ion, did:web, did:key, did:peer, did:ethr, Decentralized Identifiers Type: Report Date: 2021-04-04 Event: IIW

This report evaluates a selection of DiD methods using the guidelines specified in the W3C DiD method Rubric V1.0 (draft 06 January 2021). The evaluation reflects the authors’ opinion based on documents and source code that are publicly available. The report mainly includes a comprehensive evaluation.

• Critera for DID Method Evaluation From: IDCommons By: Walid Fdhila, Markus Sabadello Related: Decentralized Identifiers Type: Guidance Date: 2021-05 Event: IIW

The criteria selected for did evaluation are derived from (i) did rubric and (ii) principles of SSI.
(i) https://w3c.github.io/did-rubric/
(ii) https://github.com/WebOfTrustInfo/self-sovereign-identity/blob/master/self-sovereign-identity-principles.md

DID Methods

• did:abt: From: ArcBlock Type: Specification Date: 2019-10-11

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.

• did:btcr: From: CCG By: Christopher Allen, Ryan Grant, Kim Hamilton Duffy Type: Specification Date: 2019-08-08

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.

• 
• did:stack: From: Blockstack By: Jude Nelson Type: Specification Date: 2019-07-19

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: From: WebofTrustInfo By: Markus Sabadello, Fabian Vogelsteller, Peter Kolarov Type: Specification Date: 2018-02-21 Event: rwot06 Tech: ERC725

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.

• did:example: From: DIDWG Type: Specification Date: 2022-07-19

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.

• 
• did:ipid: From: TranSendX Type: Specification Date: 2018-12-31

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.

• did:life: From: lifeID Foundation By: lifeID Type: Specification Date: 2019-08-13

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.

• did:sov: From: Sovrin Foundation By: Mike Lodder Type: Specification Date: 2023-04-19

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.

• did:ethr: From: uPort Type: Specification Date: 2022-11-07 Tech: ERC1056, secp256k1

ETHR DID Method Specification

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, or any secp256k1 public key to become a valid identifier. Such an identifier needs no registration. In case that key management or additional attributes such as “service endpoints” are required, they are resolved using ERC1056 smart contracts deployed on the networks listed in the registry repository.

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.

• DID resolver for Ethereum Addresses with support for key management (and DID reference implementation) From: DIF Type: Code Tech: did:ethr:, secp256k1

This library is intended to use ethereum addresses or secp256k1 publicKeys as fully self-managed Decentralized Identifiers and wrap them in a DID Document

• did:v1: From: Digital Bazaar Type: Specification Date: 2019-11-22 Tech: SHA-256

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.did:v1:nym:4jWHwNdrG9-6jd9I7K1si3kTRneNwftZV9m6rkrAfWQThe 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.did:v1:uuid:804c6ac3-ce3b-46ce-b134-17175d5bee74

• 
• Veres One (did:v1) Rubric Evaluation From: Veres One By: Joe Andrieu Related: did:v1: Type: Session notes Date: 2021-05-06

Veres One, DID Rubric Evaluation, DID methods, DIDs,

• did:com: From: Commercio Consortium Type: Specification Date: 2019-11-12 Sector: Cosmos Focus: Business Documents

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.

• did:ont: From: Ontology Foundation Type: Specification Date: 2018-08-11

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.

• did:vvo: From: Vivvo Application Studios Type: Specification Date: 2020-12-18

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: From: Aergo Type: Specification

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 […] Since each Aergo transaction must be funded, in order to update attributes, account balance must be greater than zero.

• did:icon: From: ICONLOOP Type: Specification Date: 2019-08-14

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.

• did:is: From: Blockcore Type: Specification Date: 2020-08-31

This specification describes how the Blockcore Identity framework aligns with the DID specification and how the Blockcore Universal Resolver works.[…]The Blockcore Identity registry is a permissionless and borderless runtime for identities.

• did:iwt: From: Raonsecure Related: Verifiable Credentials Type: Specification Date: 2019-02-18

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.

• did:ockam: From: Ockam Type: Specification Date: 2018-11-18

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.

• did:ala: From: Alastria National Blockchain Ecosystem Type: Specification Date: 2022-02-22 Tech: Quorum

This document is divided into two parts:
- 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.

• did:op: From: Ocean Protocol Type: Specification Date: 2021-04-28

Requirements are:
- The DID resolving capabilities MUST be exposed in the client libraries, enabling to resolve a DDO directly in a totally transparent way
- ASSETS are DATA objects describing RESOURCES under control of a PUBLISHER
- KEEPER stores on-chain only the essential information about ASSETS
- PROVIDERS store the ASSET metadata off-chain
- KEEPER doesn’t store any ASSET metadata
- OCEAN doesn’t store ASSET contents (e.g. files)
- An ASSET is modeled in OCEAN as on-chain information stored in the KEEPER and metadata stored in OCEANDB
- ASSETS on-chain information only can be modified by OWNERS or DELEGATED USERS
- ASSETS can be resolved using a Decentralized ID (DID) included on-chain and off-chain
- A DID Document (DDO) should include the ASSET metadata
- Any kind of object registered in Ocean SHOULD have a DID allowing one to uniquely identify that object in the system
- ASSET DDO (and the metadata included as part of the DDO) is associated to the ASSET information stored on-chain using a common DID
- A DID can be resolved to get access to a DDO
- ASSET DDOs can be updated without updating the on-chain information
- ASSET information stored in the KEEPER will include a checksum attribute
- The ASSET on-chain checksum attribute SHOULD include a one-way HASH calculated using the DDO content
- After the DDO resolving, the DDO HASH can be calculated off-chain to validate if the on-chain and off-chain information is aligned
- A HASH not matching with the checksum on-chain means the DDO was modified without the on-chain update
- The function to calculate the HASH MUST BE standard

• did:jlinc: From: JLinc.org By: Victor Grey Type: Specification Date: 2018-10-13

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.

• did:ion: From: DIF Type: Specification Date: 2023-04-20

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, 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.

• did:jolo: From: Jolocom Type: Specification Date: 2020-08-16 Tech: ION, Sidetree

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.

• did:bryk: From: Bryk By: Marcos Allende, Sandra Murcia, Flavia Munhoso, Ruben Cessa Type: Specification Date: 2021-12-27 Tech: IPFS

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.

• did:peer: From: Daniel Hardman Type: Specification Date: 2022-10-13

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.

• Peer DIDs — An Off-Ledger DID Implementation From: Affinidi Related: did:peer: Type: Page Date: 2021-05-18

• 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.

• did:selfkey: From: SelfKey Type: Specification Date: 2019-04-10

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 as specified by the W3C Credentials Community Group.

The functionality for this method is provided by the DIDLedger smart contract found in this repository.

• did:meta: From: Metadium Type: Specification Date: 2021-06-02

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

• did:tys: From: Chainyard Type: Specification Date: 2019-04-23 Focus: Lifecycle Managment

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.

• did:git: By: Dave Huseby Type: Specification Date: 2019-06-06 Event: Internet Identity Workshop Tech: DAG

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 Cryptography Protocol From: cryptidtech By: Dave Huseby Type: Specification Date: 2021-08-14 Focus: Software Development

This specification documents a new, proposed protocol Git uses when interacting with cryptographic signing and verification tools. The goal of this modification is to make Git able to use any signing and verification tools. The design eliminates all of the tool-specific code in Git, easing maintenance and increasing flexibility. The protocol takes is inspired by the Assuan Protocol used by GPG to link its component executables together but uses Git’s pkt-line framing.

• did:tangle: From: BiiLabs Type: Specification Date: 2022-06-06

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.

• did:emtrust: From: Halialabs Type: Specification Date: 2019-06-17

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.

• did:ttm: From: Token.TM Type: Specification Date: 2019-07-11

<32 byte hexadecimal stringcorresponds 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.

• did:wlk: From: Weelink Type: Specification Date: 2019-07-19

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.

• did:pistis From: Pistis By: Andrea Taglia, Matteo Sinico Type: Specification Date: 2019-08-29

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.

• did:holo: From: Holo.Host Type: Specification Date: 2019-09-08

Decentralized Identifiers (DIDs, see [1]) are designed to be compatible with any distributed ledger or network (called the target system). We will be specing and prototyping a DID method for holochain.

• did:web: From: CCG By: Oliver Terbu, Mike Xu, Dmitri Zagidulin, Amy Guy Type: Specification Date: 2023-05-06

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.did:web:w3c-ccg.github.io:user:alice

• did:io: From: IoTeX Foundation Type: Specification Date: 2021-07-28

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

• did:vaultie: From: Vaultie Inc. Type: Specification Date: 2020-08-19

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.

• did:moac: From: MOAC Blockchain Tech, Inc. By: David Ricardo Wilde Type: Specification Date: 2019-10-03

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.

• did:omn: From: OmniOne Type: Specification Date: 2019-05-30

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.

• did:work: From: Workday, Inc. Type: Specification Date: 2020-06-25

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.

• 
• did:vid: From: VP Inc. Type: Specification Date: 2019-10-15

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.

• did:ccp: From: Baidu, Inc. Type: Specification Date: 2016-02-08

Application scenarios:
- Digital identity
- Joint member key customer system
- Financial KYC
- Exchange
- Smart City
- IoT deviceless identity management

Program features:
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:jnctn: From: Jnctn Limited Type: Specification

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.

• did:evan: From: evan GmbH Type: Specification Date: 2020-03-24

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.

• did:elastos: From: Elastos Foundation Type: Specification Date: 2021-01-04

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.

• did:kilt: From: BOTLabs GmbH Type: Specification Date: 2022-10-11

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.

• did:elem: From: Transmute Type: Specification Date: 2020-04-06 Tech: Element DID

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

• did:github: From: Transmute Type: Specification Date: 2020-05-08

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.

• did:bid: From: teleinfo caict Type: Specification Date: 2022-11-03

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.

• did:ptn: From: PalletOne Type: Specification Date: 2020-02-29

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: From: Echo Technological Solutions LLC Type: Specification Date: 2022-10-11

We propose a new DID method that allows special objects in ECHO network to be treated as valid DIDs.

• did:trustbloc: From: SecureKey Type: Specification Date: 2020-04-09

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.

• did:san: From: YLZ Inc. Type: Specification Date: 2020-04-17

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.

• did:gatc: From: Gataca Type: Specification Date: 2020-05-05

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.

• did:factom: From: Sphereon, Factomatic, Factom Inc Type: Specification Date: 2019-11-02

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.

• did:signor: From: Cryptonics Consulting Type: Specification Date: 2020-11-16

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: From: Hedera Hashgraph, Swisscom Blockchain AG Type: Specification Date: 2020-05-14

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.

• did:sirius: From: ProximaX Enterprise, Proximax Inc. Type: Specification Date: 2020-07-04

The target system is the ProximaX Sirius Chain network. This can either be:
- Sirius Chain on Main Net
- Sirius Chain on Test Net
- Sirius Chain on Private Net

• did:dock: From: Dock Type: Specification Date: 2022-07-21

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.

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.

• did:twit: From: did-twit Type: Specification Date: 2020-07-29

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 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, is to encourage use of the DID Spec, by lowering the barrier to entry for use of the technology, and promote higher trust interactions.

• did:near: From: Ontology Foundation Type: Specification Date: 2020-08-02

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: From: China Academy of Information and Communications Technology (CAICT) Type: Specification Date: 2020-08-05

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 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.

• did:bba: From: Attila Aldemir Type: Specification Date: 2020-08-31

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.

• did:morpheus From: Hydra Hashgraph Type: Specification

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.

• did:etho: From: Ontology Foundation Type: Specification Date: 2020-08-14

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: From: Ontology Foundation Type: Specification Date: 2020-08-14

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.

• did:celo: From: Ontology Foundation Type: Specification Date: 2020-08-14

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.

• did:klay: From: Ontology Foundation Type: Specification Date: 2020-08-14

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.

• did:trx: From: Ontology Foundation Type: Specification Date: 2020-08-14

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:grg: From: GRGBanking Blockchain Express Type: Specification Date: 2020-08-01

GRG did document security authentication is based on the cryptography algorithm. A signature is used to verify that the claim is from a trusted did user. What should be noted is the authenticity verification of the issuer. An alliance blockchain maintained by an official organization is designed and used. In the alliance chain, the did document of the certification authority should be stored, and its did ID number should be displayed on the official website of the relevant organization. Therefore, the verifier can verify claims based on this information.

• did:schema: From: 51nodes GmbH Type: Specification Date: 2020-08-26

The Schema Registry DID Method aims to provide unique and universal identification for schemas in multiple formats hosted on multiple storage mechanisms or networks.

• did:key From: CCG By: Rick Astley, Manu Sporny, Dmitri Zagidulin, Dave Longley, Orie Steele Type: Specification Date: 2022-09-02

Ledger independent DID method based on public/private key pairs.

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

• did-key-creator published From: CCG Related: did:key Type: Code Date: 2022-11-03

This has been tested to create did:keys from the P-256,P-384, and P-521 curves specified in https://github.com/w3c-ccg/did-method-key and https://w3c-ccg.github.io/did-method-key/

• Rust implementation of the did:key method From: Crates By: Tomislav Markovski Related: did:key Type: Code Date: 2022-11-28

This crate is intended to provide basic support for did:key methods. It has no external dependencies and can be compiled for any target. It was originally designed for use with DIDComm Extension for gRPC, but we recognized it may be useful if this was an independent library

• did:tyron: From: Tryon By: Julio, Cabrapan Duarte Type: Specification

Tyronzil is the W3C Decentralized Identifier Method of the Tyron Self-Sovereign Identity Protocol. You can find it published at the W3C DID Specification Registries, and it is the first DID Method of the Zilliqa blockchain - funded by ZILHive Innovation grants.

• did:corda: From: Persistent Systems, R3 By: Nitesh Solanki, Moritz Platt, Pranav Kirtani Type: Specification Date: 2020-09-21

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: From: Space Elephant Type: Specification Date: 2020-10-16 Focus: NFT

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, 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.

• did:panacea: From: MediBloc Type: Specification Date: 2020-10-10

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.

• did:indy: From: Hyperledger Foundation Type: Specification Date: 2023-02-23

Indy is a public ledger designed specifically and only for privacy-preserving self-sovereign identity. A Hyperledger Indy ledger is designed specifically to enable the use of verifiable credentials, allowing credential issuers to publish data necessary for issuing verifiable credentials and constructing presentations from those verifiable credentials. This specification covers how DIDs on an Indy ledger are managed and the operations for creating, reading, updating, and deleting DIDs.

• The did:indy DID Method - Future Indy Ledgers From: IDCommons By: Stephen Curran Related: did:indy: Type: Session notes Date: 2021-05-06 Event: IIW

Getting involved with this work:

• did:indy Presentation From: BCGov By: Stephen Curran Related: did:indy: Type: Presentation Date: 2021-04-20

• Namespaced DIDs useful across all Indy instances
  - Indy network discovery
  - Full DIDDoc support
  - Namespaced identifiers for other Indy objects (schemas, etc.)
  - Support for important resolution parameters
  - E.g. version-id, version-time, resource
  
  Nice to have (but not likely to be there):
  - Cross-ledger registration of networks for discovery
  - Support for KERI identifiers on Indy networks
  
  Getting involved with this work:
  - HackMD Document with current spec
  - Home of future spec: indy-did-method
  - Meeting Wiki and schedule
  - Hyperledger indy-did-method chat channel

• did:onion: From: Blockchain Commons Type: Specification Date: 2021-08-06

🧅 part of the torgap technology family
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 keep did:onion to did:web, and if we want to incorporate some elements of did:peer or KERI or to leverage services like Open Time Stamps.

• did:nft: From: Ceramic Type: Specification Date: 2021-02-12

The NFT DID Method converts any non-fungible token on any blockchain into a decentralized identifier where the owner of the NFT is the controller of the DID. This is achieved by using the Chain Agnostic Improvement Proposals to describe NFT assets and blockchain accounts, as well as the Ceramic network to find the DID associated with the owner of the NFT.

• did:eos: From: Gimly Type: Specification Date: 2021-06-30

1. Identity - the management of accessible public key infrastructure and identifies. Decentralized Identifiers is the W3C standard that allows this. Compliance with this standard allows application layers to interoperate without a need to understand the base layer decentralised protocols that power identities.
   2. Application - use of the identity layer to interact and provide meaningful, secure and verifiable data communications and interaction. The Verifiable Credentials W3C standard is the most prominent and adopted standard here which is a data structure and message protocol allowing people and organisations to securely and in a verifiable way send and verify information about themselves “credentials” to each other. DIDComm is another important application layer that uses DID methods to communicate between SSI identities.

• The EOSIO DID method specification From: Gimly Related: did:eos: Type: Post Date: 2021-04-02

We have been working with the Decentralised Identity Foundation to shape this specification, and also want to thank the W3C Credentials Community Group for their support in the creation of the Verifiable Condition type, a necessary component to create the EOSIO DID document to represent EOSIO account permissions.

• did:did: From: SpruceID Type: Specification Date: 2021-04-01

DID Identity DID (DID) DID method

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.

• did:undid: From: SpruceID Type: Specification Date: 2021-04-01

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.

Clarification, a few week ago we shared about the DID:DID method. April Fools Joke!!! Here’s yet another DID method in the series.

• did:doge: From: SpruceID Type: Specification Date: 2023-05-04

We draw heavily from prior work by Christopher Allen and Kim Hamilton Duffy within the W3C Credentials Community Group on the BTCR DID Method due to strong architectural similarities between the Bitcoin and Dogecoin blockchains.

However, there are some key differences that enable new privacy-preserving benefits. Namely, the did:doge method-specific identifier is the Base58Check-encoded Dogecoin address itself, allowing for DID usage even in the absence of any public transaction histories and only relying upon them for rotation events for verification methods and service endpoints.

• did:tz: From: SpruceID, TQ Tezos Type: Specification Date: 2022-01-13

did:tz is a multi-modal DID method design with many offchain, on-chain, and side-chain/L2 use cases in mind. A valid Tezos address (controlled by a private key from any of 3 supported curves) can control an “implicit” DID document (generatively created from the address like a did:key), an “onchain” DID document (published via smart contract on any Tezos ledger), or have “patches” applied to it that are published and governed by a closed network or authority (including, for example, a sidetree network). In particular, this third option has not been specified in any detail, and we would be particularly curious to hear from implementers of such systems before further specifying it.

• Decentralized Identity with the Tezos DID Method From: SpruceID, TQ Tezos Related: did:tz: Type: Post Date: 2021-03-03

Spruce and TQ Tezos are jointly releasing the draft specification and initial implementation of Decentralized Identifiers (DIDs) based on the Tezos blockchain.

• did:unisot: From: Unisot Type: Specification Date: 2020-11-25

The UNISOT DID method uses the Bitcoin SV blockchain to generate DIDs as well as potentially store the associated DID documents. The method allows for storage of DID documents on-chain as well as off-chain depending on the business use case scenario.

• UNISOT DID approved by W3C From: Unisot By: Annemie Bergmans Related: EBSI, did:unisot Type: Post Date: 2021-05-25 Policy: ESSIF, GDPR

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/. With this anyone can resolve a UNISOT DID Document in a trusted and easy way.

• did:orb From: SecureKey Type: Specification Date: 2022-03-21

Orb is a decentralized identifier (DID) method based on a federated and replicated Verifiable Data Registry (VDR). The decentralized network consists of Orb servers that write, monitor, witness, and propagate batches of DID operations. The batches form a graph that is propagated and replicated between the servers as content-addressable objects. These content-addressable objects can be located via both domain and distributed hash table (DHT) mechanisms. Each Orb witness server observes a subset of batches in the graph and includes them in their ledgers (as append-only Merkle Tree logs). The servers coordinate by propagating batches of DID operations and by monitoring the applicable witness servers’ ledgers. The Orb servers form a decentralized network without reliance on a common blockchain for coordination.

• 
• Orb From: SecureKey Related: did:orb: Type: Code Date: 2023-05-25 Projects: Trustbloc Tech: ActivityPub, ActivityStreams, Sidetree

Orb implements the following specifications: did:orb, Activity Anchors. The did:orb method is based on the Sidetree specification and Activity Anchors is based on the ActivityPub and ActivityStreams specifications.

Please see Read the Docs for more details on Orb

• SecureKey’s New Ledger-Agnostic did:orb From: SecureKey Related: did:orb: Type: Post Date: 2021-06-10 Tech: ActivityPub, IPFS, verifiable credentials

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.

• did:orb slides Troy Ronda (SecureKey) From: CCG Mailing List By: Troy Ronda Related: did:orb:, Type: Presentation Date: 2021-03-03

• Decouple witness ledgers from the critical path.
  - Allow for Trust but Verify model.
  - Leverage the Certificate Transparency model
  - Witnesses observe VDR objects and promise to include in their ledgers.
  - Provide a signed timestamp and a maximum merge delay.
  - Enable monitoring to ensure witnesses follow their promises.
  - Use trusted Witness (and origin) timings to resolve late publishing.
  - Use origin to enable observers to know if they have the latest operations.

• did:object From: Trusted Digital Web By: Michael Herman Type: Specification Date: 2022-01-26

This “DID Object” Decentralized Identifier Method Namespace Specification (“DID Object” DID Method Namespace Specification) defines the end-to-end lifecycle of DID Identifiers and DID Documents for “DID Objects”, a key feature of the Fully Decentralized Objects (FDOs) Framework, implemented by the Trusted Digital Web.

• did:tag By: Bob Wyman Type: Specification Date: 2021-11-02

The did:tag DID method enables any controller of an HTTP accessible domain or subdomain, or of an email address, to create unique, interoperable, persistent DIDs with minimal dependencies on other technologies or systems. By leveraging a subset of the tagURI specification [RFC4151], the did:tag DID method enables the creation of DIDs which are “unique across space and time while being tractable to humans,” without preventing the creation of DIDs which are largely intractable to humans. did:tag DIDs can be resolved either synchronously, via the web, or asynchronously, via email or other defined alternative resolution services.

• re: Using Email as an Identifier From: CCG Mailing List By: Bob Wyman Type: Discussion Date: 2021-11-12

There are quite a number of issues with using email addresses as identifiers, or parts of identifiers, and I’m hoping that discussion and development of the did:tag method will illuminate those issues and potentially find solutions for them.

• did:jwk From: waltid, transmute Related: did:key Type: Specification Date: 2022-04-14 Tech: JWK

did:jwk is a deterministic transformation of a JWK into a DID Document.

• did:pkh From: CCG Type: Specification Date: 2023-01-27

allows most if not all blockchain accounts to instantly leverage an existing identity/account and deploy a W3C Decentralized Identifier from it in a standards-conformant way. This “DID-wrapping” of an existing identifier can be used in combination with other DID-compatible technologies, such as W3C Verifiable Credentials or Authorization Capabilities, and produce proper signature-suite definitions, such as “metamask-signing” (off-chain signing by externally-owned accounts, i.e., personal wallets, according to the eip712 protocol).

• Verification Patterns, Part 2 From: Verite Related: did:pkh Type: Post Date: 2022-07-27

explains the did:pkh/CACAO variation for Verite data models and flows, which provides an entry path for wallets that may not support sufficient functionality for emerging decentralized identity patterns

• 
• did:ens From: Veramo Labs Type: Specification Date: 2021-10-05

1. to wrap existing ENS names as DIDs to be interoperable with applications relying on Decentralized Identifiers
   2. to define a canonical way to augment ENS names with DID capabilities such as services and verification methods.

• ENS names are Decentralized Identifiers (DIDs) From: uPort By: Oliver Terbu Type: Post Date: 2021-10-19

The specification is extensible by design which means new types of services, verification materials and other features can be supported. In the core, the specification contains a simple interface to resolve a DID Document from a DID (similar to an Ethereum Account from an ENS name) by anyone who knows the DID of the user. The DID Document will then contain the relevant information to enable use cases such as sign up, sign in, data encryption, secure communication, verifiable authorship and data provenance etc. Since DIDs are URI-compliant, they also make perfect sense for web ontologies.

• did:avvcyber: From: TIFAC-CORE in Cyber Security By: Ramaguru Radhakrishnan, Amrita Vishwa Vidyapeetham Type: Code Date: 2022-01-01

TIFAC-CORE in Cyber Security, Amrita School of Engineering, Amrita Vishwa Vidyapeetham Coimbatore is Center of Relevance and Excellence (CORE) in Cyber Security. The Center is working toward Cryptography, Visual Cryptography, Steganography, Cyber Forensics, Machine Learning and Blockchain Technology. There are multiple projects being worked across domains where we are using DIDs. did:avvcyber: is a dedicated DID created for all our Blockchain Projects from 2022.

Discussion

• DID methods as W3C standards - a happy compromise? From: CCG Mailing List By: Steve Capell Type: Discussion Date: 2022-02-22 Focus: Methods as Standards

can’t we pick just a small number of un-controversial methods to standardise?  even if it’s just did:key and did:web to start with.

• Re: CCG Community opinions needed to define CCG scope (specifically re: did methods as work items) From: CCG Mailing List By: Manu Sporny Type: Discussion Date: 2021-08-26 Focus: Methods as Standards

Heather Vescent wrote:
1. What are the pros of including did methods as work items in the CCG?
Community vetting and approval of particular DID Methods.

Basically, broader and deeper review of DID Methods that we expect to be of great use to the world. I expect there will be DID Methods that the community wants to eventually propose as DID Methods for standardization (did:key and

did:web feel like two ones where we could get consensus on doing so).