Table of contents
W3C DID standard
Decentralized Identifier (DID) is a new type of identifier that is globally unique, resolvable with high availability, and cryptographically verifiable. DIDs are often associated with cryptographic material (such as public keys) and service endpoints to establish secure communication channels. DIDs are useful for any application that benefits from self-managing, cryptographically verifiable identifiers such as personal identifiers, organizational identifiers, and IoT scenario identifiers. For example, current commercial deployments of W3C verifiable credentials make heavy use of DIDs to identify people, organizations, and things, and achieve many security and privacy protection guarantees.
- W3C document
On the surface, a decentralized identifier (DID) is just a new type of globally unique identifier, but at a deeper level, a DID is a new distributed digital identity for the Internet, and it is also a public key infrastructure (PKI) layer core component. This distributed public key infrastructure (DPKI) may have as much influence on global cybersecurity and privacy as the SSL/TLS protocol for encrypting web traffic (now the world's largest PKI)
The DID system under the DID standard of W3C mainly includes the following hierarchical elements:
Basic layer: DID specification
1. DID identifier (Identifier)
entities are identified by decentralized identifiers (DID). They can be authenticated through proofs (e.g., digital signatures, privacy-preserving biometric protocols, etc.).
2. DID document (Document)
DID points to the DID document. A DID document contains a set of service endpoints for interacting with entities. Following the adage of privacy by design, each entity can have as many DIDs as it needs to respect the entity's desired separation of identities, personas, and contexts. (Note that there is no content related to your real personal information in the DID document, such as your real name, address, mobile phone number, etc. Therefore, it is impossible to verify a person's identity by relying on the DID specification alone, and it must rely on the DID application layer. VC.)
Application Layer: Verifiable Claims
Verifiable Claims (Verifiable Claims or Verifiable Credentials, referred to as VC in this article)
1. Background
1. The motivation of DID
The growing need for decentralized identifiers has created two specific requirements for new types of URLs that still fit the web architecture, and there are some additional requirements that more traditional URLs, such as HTTP-based URLs, do not: (
a ) New types of URLs should not require centralized authority to register, resolve, update, or revoke identifiers. The vast majority of URIs today are based on DNS names (domain names) or IP addresses, which rely on a centralized authority for registration and ultimate control. DIDs can be created and managed without any such permissions (URI and URL detailed links: https://blog.csdn.net/readiay/article/details/52862379).
(b) URLs whose ownership and associated metadata (including public keys) can be cryptographically verified. Authentication via DIDs and DID documents utilizes the same public/private key cryptography as distributed ledgers.
2. The role of human-friendly identifiers
DIDs achieve global uniqueness without the need for a central registry, however, this comes at the expense of human memorability – algorithms capable of generating globally unique identifiers automatically generate random strings that have no human meaning. This proves an axiom about identifiers known as Zooko's triangle: "Humans make sense, decentralize, and safely pick any two"
2. The difference between DID and other globally unique identifiers
For self-sovereign identities, which can be defined as permanent, portable identities that do not rely on any authority's centralized authority, we need a new identifier that satisfies all four requirements: persistent, globally resolvable, cryptographically verifiable, and decentralized sex
3. The format of DID
Four, DID file (DID Document)
DID's infrastructure is a globally scalable database that includes all DID-compatible blockchains, distributed ledgers or decentralized networks. In this virtual database, the key is the DID and the value is the DID document. The purpose of a DID document is to describe the public keys, authentication protocols, and service nodes necessary to bootstrap cryptographically verifiable interactions of identified entities.
A DID document is a valid JSON-LD object that uses the DID context (RDF vocabulary of property names) as defined in the DID specification. This includes six components (all optional):
(1) the DID itself, and thus the DID document is completely self-describing
(2) a set of cryptographic material, such as a public key, that can be used to authenticate or interact with the DID subject
(3) a set of cryptographic protocols for interacting with the DID subject, such as authentication and functional division
(4) a set of service endpoints describing where and how to interact with DID subjects
(5) audit timestamps
(6) optional JSON-LD signatures to verify the integrity of DID documents .
5. DID Algorithm
It is the role of the DID algorithm specification to define how DIDs and DID documents are created, parsed and managed on a particular blockchain or "target system".
DID algorithm specifications typically define the following operations for a specific target system:
(1) CREATE. Some DID algorithms can generate DIDs directly from cryptographic key pairs, others can use transaction addresses or smart contracts on the blockchain.
(2) read. Some DID algorithms use blockchains that can store DID documents directly on the blockchain. Others might instruct the DID resolver to dynamically construct them based on the attributes of the blockchain record. Still others can store pointers on the blockchain to DID documents in one or more parts on other distributed storage networks such as IPFS or STORJ.
(3) UPDATE. From a security point of view, the update operation is the most critical, since the control table of the DID document controls the public key or evidence required for the entity to authenticate (so an attacker can impersonate the entity). Since verification of DID document update permissions can only be enforced by the target blockchain, the DID algorithm specification must define precisely how authentication and authorization will be performed for any update operation.
(4) delete. DID entries on the blockchain are immutable by definition, so they can never be "deleted" in the traditional database sense, however, they can be revoked in the cryptographic sense. The DID algorithm specification must define how this termination is performed, for example, by writing an empty DID document.
6. DID and Privacy by Design
(1) In pairs. While DIDs can be used as well-known public identifiers, they can also be used as private identifiers issued on a per-relationship basis, so compared to a person with a single DID (such as a mobile phone number or national identity number), she can Having thousands of pairwise unique DIDs that cannot be linked without her consent, but can still be managed as easily as an address book (identity avatar).
(2) Offline private data. Storing any type of personally identifiable information (PII), even encrypted or hashed, on a public blockchain is dangerous for two reasons: 1) encrypted or hashed data is a global point of association when sharing data with multiple parties, 2) If the encryption is eventually broken (e.g., quantum computing), the data will always be accessible on an immutable public ledger. Therefore, it is best practice to store all private data off-chain and only exchange it over encrypted private peer-to-peer connections.
(3) Selective disclosure. Decentralized PKI (DPKI) enabled by DID offers two ways for individuals to have greater control over their personal data. First, it allows it to be shared using encrypted digital credentials; second, these credentials can use zero-knowledge proof cryptography to minimize data, for example, you can disclose that you are over a certain age without revealing your exact birthday.
7. DID and Verifiable Certificate (VC)
DID is just the base layer of a distributed identity infrastructure, the next level up is verifiable credentials, which is the technical term for digitally signed electronic credentials that conform to the interoperability standards being developed by the W3C Verifiable Claims Working Group.
DIDs can be used to identify various entities in the verifiable credential ecosystem, such as issuers, holders, subjects, and verifiers, and more generally, DIDs can be used as identifiers for people, devices, and organizations
Reference link:
Zhihu-Decentralized Identifier DID