or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
![image alt](https:// "title") | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | Emoji list | ||
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Decentralized Identifiers
Authors
Participate
Table of Contents
Introduction
A decentralized identifier, or DID, is a new URI scheme. Unlike existing HTTP URLs, email addresses, commercial account identifiers, most government identifiers, etc., the DID was purpose-designed to support cryptographically-controlled identifiers backed by a decentralized oracle (such as a distributed ledger or blockchain).
Syntactically, a DID looks like this:
did:btcr:xyv2-xzpq-q9wa-p7t
. The three parts of a DID, separated by colons, are:did
URI scheme.btcr
, that must be one of the values in the to-be-created DID Registryxyv2-xzpq-q9wa-p7t
.Goals
Non-Goals
Key scenarios
For key scenarios, please see Use Cases and Requirements for Decentralized Identifiers
We specifically encourage reviewing the set of focal use cases from that document.
Detailed design discussion
Identifiers, not Identity
It is important to note that a DID is a decentralized identifier, and not a decentralized identity. While a DID could be used as an identifier in an identity system, the standard itself is expected to only define the identifier itself, making no claims about interpretability as an identity.
Although the standard will not expressly enforce privacy, it is a strong goal of the work that DIDs, and specific DID methods, can be used in ways that strongly reduce correlatability of personally-identifiable information.
DID Methods
A key component of the decentralized identifier specification is the notion of DID methods. DID methods are a means by which DIDs are "decentralized", as any number of DID methods may be created, each with different properties and assurances. The DID specification defines what a conforming DID method specification must contain. A DID method specification describes a particular type of DID and defines how it may be created, updated, resolved, or deactivated. It also must provide security and privacy considerations for that DID method.
Assertion of Control of a DID
A key property of a DID is that it has a controller. Commonly, this entity will use public-key cryptography to assert control of a DID. This assertion of control may be used as an authentication mechanism. The standard does not define new authentication mechanisms, but does reference existing ones.
DID Documents
For some DID methods the URI string itself is sufficient to understand how to verify control over the DID, including key rotation and revocation. An example is the “key” method, which interprets the third part of the DID as a public key. To support other, more complex, DID interactions, the concept of a DID document is introduced. This document typically provides other details regarding how to assert control over the DID or connect with the DID subject. The DID Document for a DID may change over time, but at any moment, there is only one DID Document for a DID. A DID method defines how a DID resolves to a DID document for that method. Here is an example DID document.
DID Resolution
Just as with HTTP URIs, DIDs are expected to be resolved and dereferenced. As per https://tools.ietf.org/html/rfc3986, resolution is the process of determining the operations that can be performed on/with the resource identified by the DID, along with any access control or authorization. Resolution results in a DID Document and possibly some metadata about the resolution process. Though the resolution process itself is out of scope for this version of the DID specification, the specification does define abstract function signatures that a conforming DID resolver must implement against. For more detail, please refer to the specification.
DID Dereferencing
Dereferencing is the process of performing the operations identified during resolution. One directly supported capability today is the use of service endpoints. Service endpoints
Considered alternatives
The alternatives that prompted the creation of DIDs were considered well before the initiation of the Working Group to develop this specification from the preliminary work done by the Credentials Community Group. Listed here are some of the other identifier approaches whose characteristics motivated the creation of DIDs.
Proprietary account names
A common identifier nowadays is a username or email address. These identifiers tend to be issued by entities that can, administratively, change or remove them without the permission or even knowledge of the identifier holder. DIDs were explicitly created to allow for an identifier that could not be modified or taken away from a controller by any third party.
Open ID / OIDC
One possible use for DIDs is as an authentication mechanism. While at first glance it may appear that DIDs compete with existing authentication mechanisms such as OIDC or WebAuthn, they are actually complementary to such technologies and with some effort may even be incorporated with them.
Other URI Schemes
Some of the uses of DIDs may be possible with existing URI schemes. What DIDs provide that the others do not is the unique combination of the following characteristics:
Stakeholder Support or Opposition
There is broad interest in and support for DIDs across the identity community. Early in the Working Group's history there was a concern around DID Documents only having a JSON-LD-based format defined. Since then the specification has added both JSON-only and CBOR formats. The number of entries already in the DID Method Registry is evidence of the interest in this work.
References and acknowledgements
In alphabetical order, many thanks for valuable feedback and advice from Juan Caballero and participants in: