Decentralized Identifiers (DIDs) - W3C
Main
- A Primer for Decentralized Identifiers From: CCG Type: Report Date: 2021-11-11
- Decentralized IDentifers (DIDs) From: W3C By: Markus Sabadello Related: Danube Tech, Sovrin Foundation, OASIS XDI TC Type: Presentation Date: 2018-04-17 Location: Vienna Event: W3C Workshop on Privacy and Linked Data
- Developed at Rebooting-the-Web-of-Trust workshop and W3C Credentials CG
- Persistent, dereference-able, cryptographically verifable identifers
- Registered in a blockchain or other decentralized network 
- Decentralized Identifiers (DID) 1.0 specification approved as W3C Recommendation From: Identity Foundation Type: Post Date: 2022-06-22
- Decentralized Identifier Working Group From: DIDWG Related: W3C Type: Working group Established: 2019-05-31
- Decentralized Identifier (DID) 1.0 Specification - Data Model and Syntax From: DIDWG Type: Specification Date: 2022-07-19
- DID Specification Registries From: DIDWG Type: Registry Date: 2023-05-14
An introduction to self-administered identifiers for curious people
Announcing the Decentralized Identifiers (DID) v1.0 specification as an open web standard signals that it is technically sound, mature, and ready for widespread adoption. Having an established v1.0 specification allows work to continue with renewed energy and focus, not only at the many groups meeting at DIF, but across the digital identity community.
The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.
This document specifies the DID syntax, a common data model, core properties, serialized representations, DID operations, and an explanation of the process of resolving DIDs to the resources that they represent.
This document serves as an official registry for all known global parameters, properties, and values used by the Decentralized Identifier ecosystem.
Explainer
- Understanding Decentralized IDs (DIDs) By: Adam Powers Type: Post Date: 2018-06-02
- What is a DID? The Path from an id (DID) to a Real-Life Subject By: Michael Herman Type: Page Date: 2019-05-19
- Demystifying Decentralized Identifiers (DIDs) From: Affinidi Type: Post Date: 2021-05-05
- 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 
- Decentralized Identifiers (DIDs) - A Deeper Dive From: Hackernoon Type: Post Date: 2021-04-26
- Decentralized Identity: Why Are DIDs The Future of Digital Identity Management? From: Elastos Type: Post Date: 2021-10-14
- Decentralized Identifiers: Implications for Your Data, Payments and Communications From: Impervious Type: Post Date: 2022-03-22
This article starts off with an overview of DIDs, DID Documents, Verifiable Claims and DIDAuth — basically laying out how the technology works. It then explores the economics of DIDs to try and understand what problems they propose to solve, for whom, and how they go about solving them.
The following graphic illustrates the path (flow) of a client app trying to: a) communicate/interact with, and/or b) access the metadata about a real-life subject by using a Decentralized Identifier (id (DID)).
That is, in (almost) 10 steps or less, how to you get from an id (DID) attribute on the left to a Real-Life Subject on the right?
The same way the SSL/TLS protocol changed internet use forever by opening a gate to the world of encrypted Web traffic, which is the basis for the protocol that keeps the web safe and secure HTTPS; the same way will DIDs enhance the verification process in world of blockchain, such as decentralized finance.
You need to create separate digital identity credentials for each one. Only after you’ve registered with them can you access the services of each organization. And don’t forget: all free-to-use apps and websites control the storage of your data and are happy to sell access to it to third parties for profit. That’s literally their business plan: they understand the value of your data and how they can monetize it.
Through the DID Specification, service endpoints and DIDComm, Impervious has interlaced DIDs with Bitcoin Lightning, IPFS, WebRTC and resilient relays to introduce a new peer-to-peer internet standard with practical applications for mitigating censorship and surveillance risk.
Literature
- DID Whitepaper From: WebOfTrustInfo Type: Paper Date: 2016-05-18 Event: rwot02-2020
- A Universally Unique IDentifier (UUID) URN Namespace From: IETF Type: Specification Date: 2005-07
- All you need to know about sequential UUID generators From: 2ndQuadrant By: Tomas Vondra Type: Post Date: 2019-03-02
- DID Primer From: WebofTrustInfo By: Drummond Reed, Manu Sporny, others Type: Paper Date: 2017-10-06 Event: rwot05-boston
- DID Primer Extended From: WebofTrustInfo By: Drummond Reed, Manu Sporny, others Type: Paper Date: 2019-02-14 Event: rwot07-toronto
- Background on the origin of DIDs and the DID specification.
- How DIDs differ from other globally-unique identifiers.
- How the syntax of DIDs can be adapted to work with any modern blockchain.
- How DIDs resolve to DID documents containing public keys and service endpoints.
- The key role that DID methods play in the implementation of DID infrastructure. - Decentralized IDentifers (DIDs) From: DIDWG By: Markus Sabadello Related: Decentralized Identifiers Type: Presentation Date: 2018-04-17
- Developed at Rebooting-the-Web-of-Trust workshop and W3C Credentials CG
- Persistent, dereference-able, cryptographically verifable identifers
- Registered in a blockchain or other decentralized network
- did:sov:3k9dg356wdcj5gf2k9bw8kfg7a
- Modular specifcation using “methods”:
- did:sov, did:btcr, did:v1, did:uport, …
- Can be pairwise unique for each relationship
- Resolution: DID → DID Document - Requirements for DIDs From: WebofTrustInfo Related: Decentralized Identifiers Type: Paper Date: 2016-08-24 Event: rwot02-2020
- DIDs in DPKI From: WebofTrustInfo Related: Decentralized Identifiers Type: Paper Date: 2018-08-23 Event: rwot07-toronto
- DPKI stands for Decentralized Public-key Infrastructure
- DPKI seeks to serve as an improved alternative/replacement for X.509 (that thing securing today’s Internet)
- DPKI changes the web’s security model from 1000s of single-points-of-failure to decentralized consensus groups that create namespaces (sorta like what blockchains do!)
- DPKI is not a blockchain — it’s a protocol for securely accessing blockchains and similar decentralized consensus systems
- DPKI has Top-Level Domains (TLDs) representing different blockchains (e.g. .eth, .bit, .id etc.) - Cryptography Review of W3C VC Data Model and DID Standards and Implementation Recommendations From: SRI International, NIST, FIMSA Related: Decentralized Identifiers Type: Paper Date: 2023-03-19
- Decentralized Identifier Use Cases and Requirements v1.0 From: DIDWG Type: Draft Date: 2021-06-16
- Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes From: DIDWG Type: Report Date: 2019-09-13
- DID Implementation Guide From: DIDWG Type: Note Date: 2021-11-04
- W3C DID Test Suite and Implementation Report From: DIDWG Type: Internal Date: 2023-01-17
- W3C Decentralized Characteristics Rubric v1.0 From: DIDWG Type: Internal Date: 2022-01-11
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 master key recovery function
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
UUIDs are a popular identifier data type – they are unpredictable, and/or globally unique (or at least very unlikely to collide) and quite easy to generate. Traditional primary keys based on sequences won’t give you any of that, which makes them unsuitable for public identifiers, and UUIDs solve that pretty naturally.
At a superficial level, a decentralized identifier (DID) is simply a new type of globally unique identifier with special features designed for blockchains. But at a deeper level, DIDs are actually the tip of the iceberg – or the tip of the spear – of an entirely new layer of decentralized digital identity and public key infrastructure (PKI) for the Internet. This decentralized public key infrastructure (DPKI) could have as much impact on global cybersecurity and cyberprivacy as the development of the SSL/TLS protocol for encrypted Web traffic (now the largest PKI in the world).
Respect Network is conducting a research project for the U.S. Department of Homeland Security, HSHQDC-16-C-00061, to analyze the applicability of blockchain technologies to a decentralized identifier system. Our thesis is that blockchains, or more generically distributed ledgers, are a potentially powerful new tool for “identity roots” — the starting points for an Internet identity. However “blockchain identity” may not fully address the core security and privacy principles needed in a complete identity system. In this case DIDs — Decentralized Identifiers rooted on a distributed ledger — may end up being a foundational building block for higher level identity management solutions.
Cryptography used by U.S. government entities in operational systems must conform to relevant federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography. As part of its in-depth technical due-diligence to enable operational capabilities for DHS/CBP, DHS/PRIV and DHS/USCIS, the U.S. Department of Homeland Security’s Silicon Valley Innovation Program (SVIP) sponsored independent nonprofit research center SRI International to conduct a cryptographic review of the W3C Verifiable Credentials Data Model and W3C Decentralized Identifiers standards. The review provided constructive feedback and recommendations for technology developers and W3C standards developers to increase their level of compliance with federal government standards.
This document sets out use cases and requirements for a new kind of identifier that meets all these basic requirements: decentralized, persistent, cryptographically verifiable, resolvable
DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may express cryptographic material, verification methods, and/or service endpoints. These provide a set of mechanisms which enable a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject.
This document specifies a common data model, format, and operations that all DIDs support.
This document acts as a technical narrative for the implementation of DID methods and is expected to cover many topics related to that subject that a developer may wish to consider, including guidance around implementation details that may also be used for third party evaluation of an authored DID method via the DID-RUBRIC.
This document describes the did core test suite, and summarizes the latest test results.
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.
Supporting
- Well Known DID Configuration From: DIDWG Type: Specification Date: 2020-12-10
- Decentralized Identifier Resolution (DID Resolution) v0.3 From: CCG Type: Specification Date: 2023-01-18
- godiddy.com - Universal DID Services From: GoDiddy By: Markus Sabadello Type: Site Date: 2021-05-06
- Standard Interfaces for DID Create/Update/Deactivate From: IDCommons By: Markus Sabadello Type: Session notes Date: 2021-07-17
- 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. - DID test suite From: W3C Type: Code Date: 2023-01-17
- BlueToque Tools Toolkit By: Micheal Herman Type: Code Date: 2022-12-06
The DID Configuration resource provides proof of a bi-directional relationship between the controller of an origin and a DID via cryptographically verifiable signatures that are linked to a DID’s key material. This document describes the data format of the resource and the resource location at which origin controllers can publish their DID Configuration.
DID resolution is the process of obtaining a DID document for a given DID. This is one of four required operations that can be performed on any DID (“Read”; the other ones being “Create”, “Update”, and “Deactivate”). The details of these operations differ depending on the DID method. Building on top of DID resolution, DID URL dereferencing is the process of retrieving a representation of a resource for a given DID URL. Software and/or hardware that is able to execute these processes is called a DID resolver.
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.
DID test suite is not for runtime, but the Universal Resolver could do a few simple checks on a driver’s responses. But there’s also a philosophical question: Should the Universal Resolver be “allowed” to check and potentially transform driver responses, or should it just “pass through” everything that comes from a driver?
BlueToque Tools is a collection of software tools for working with DID Method Namespaces, DID Identifiers, DID Documents, DID Agent Service Endpoints, DID Agent Servers, DID Agent Clusters, and DID Objects (the 7 DIDs). The flagship tool is didlang, a language for interactively working with the 7 DIDs.
