terms.html

<p>
This document attempts to communicate the concepts outlined in the
Decentralized Identifier space by using specialized terms to discuss specific
concepts. This terminology is included below and linked to throughout the
document to aid the reader:
</p>

<dl class="termlist">

  <dt><dfn data-lt="blockchain">Blockchain</dfn></dt>

  <dd>
A specific type of <a>distributed ledger</a> technology (DLT) that
stores ledger entries in blocks of transactions that are grouped
together and hashed into a cryptographic chain. Because this type of DLT
was introduced by
<a href="https://en.wikipedia.org/wiki/Bitcoin">Bitcoin</a>,
the term "blockchain" is sometimes used to refer specifically to the Bitcoin
ledger.
  </dd>

  <dt><dfn data-lt="DID|DIDs|decentralized identifiers">Decentralized Identifier</dfn> (DID)</dt>

  <dd>
A globally unique identifier that does
not require a centralized registration authority because it is
registered with <a>distributed ledger</a> technology or other form of
decentralized network. The generic format of a DID is defined in this
specification. A specific <a>DID scheme</a> is defined in a
<a>DID method</a> specification.
  </dd>

  <dt><dfn data-lt="">Decentralized Identity Management</dfn></dt>

  <dd>
<a href="https://en.wikipedia.org/wiki/Identity_management">Identity
Management</a> based on <a>decentralized identifiers</a>.
Decentralized Identity Management extends the identifier creation authority
beyond the traditional roots of trust
required by <a href="https://en.wikipedia.org/wiki/X.500">X.500
directory services</a>, the <a href=
  "https://en.wikipedia.org/wiki/Domain_Name_System">Domain Name
System</a>, and most national ID systems.
  </dd>

  <dt><dfn data-lt="did registry|did registries|decentralized identifier registry|decentralized identifier registries">DID Registry</dfn></dt>

  <dd>
A role a system performs to mediate the creation, verification, updating, and
deactivation of <a>Decentralized Identifiers</a>.
A DID Registry is a type of Verifiable Data Registry (see [[VC-DATA-MODEL]]).
  </dd>

  <dt><dfn data-lt="">Decentralized Public Key Infrastructure</dfn> (DPKI)</dt>

  <dd>
Public key infrastructure based on
decentralized identifiers and identity records (e.g., DID Documents) containing
verifiable public key descriptions.
  </dd>



  <dt><dfn data-lt="">Dependent</dfn></dt>

  <dd>
A person, organization, or thing whose <a>DID</a> is
registered and maintained by a delegate because the dependent is not in
a position to control the private keys. A dependent becomes an
<a>identity owner</a> when the dependent takes control of the private keys.
  </dd>



  <dt><dfn data-lt="did controller|did controllers">DID Controller</dfn></dt>

  <dd>
The entity, or a group of entities, in control of a DID and/or <a>DID Document</a>.
Note that the DID Controller may or may not include the <a>DID Subject</a>.
  </dd>



  <dt><dfn data-lt="">DID Document</dfn></dt>

  <dd>
A set of data that describes the subject of a
<a>DID</a>, including mechanisms, such as public keys and
pseudonymous biometrics, that the DID subject can use to authenticate itself
and prove their association with the DID. A DID Document MAY also contain other
<a href="https://en.wikipedia.org/wiki/Attribute_(computing)">attributes</a> or
<a href="https://en.wikipedia.org/wiki/Claims-based_identity">claims</a>
describing the subject. These documents are graph-based data structures that
are typically expressed using [[JSON-LD]], but may be expressed using other
compatible graph-based data formats.
  </dd>


  <dt><dfn data-lt="">DID Fragment</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that follows the first hash
sign character (<code>#</code>). A DID fragment uses the same syntax as a URI
fragment. See Section <a href="#fragment"></a>.
  </dd>



  <dt><dfn data-lt="">DID Method</dfn></dt>

  <dd>
A definition of how a specific DID scheme can be implemented
on a specific distributed ledger or network, including the precise
method(s) by which DIDs are resolved and deactivated and DID Documents
are written and updated.
  </dd>



  <dt><dfn data-lt="">DID Path</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that begins with and includes the first forward
slash character (<code>/</code>). A DID path uses the identical syntax as a URI path.
See Section <a href="#path"></a>.
  </dd>



  <dt><dfn data-lt="">DID Query</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that follows the first question
mark character (<code>?</code>). A DID path uses the identical syntax as a URI path.
See Section <a href="#query"></a>.
  </dd>



  <dt><dfn data-lt="did subject|did subjects">DID Subject</dfn></dt>
  <dd>
The DID Subject is the entity that the DID Document is about, i.e.,
it is the entity identified by the DID and described by the DID Document.
  </dd>


  <dt><dfn data-lt="">DID URL</dfn></dt>

  <dd>
A DID plus an optional <a>DID path</a>, optional <code>?</code> character followed by a
<a>DID query</a>, and optional <code>#</code> character followed by a <a>DID fragment</a>.
  </dd>



  <dt><dfn data-lt="">DID Scheme</dfn></dt>

  <dd>
The formal syntax of a <a>Decentralized Identifier</a>. The generic DID
scheme is defined in this specification. Separate DID method specifications
define a specific <a>DID scheme</a> that works with that specific DID method.
  </dd>



  <dt><dfn data-lt="DLT">Distributed Ledger</dfn> (aka DLT)</dt>

  <dd>
A <a href=
  "https://en.wikipedia.org/wiki/Distributed_database">distributed
database</a> in which the various nodes use a <a href=
  "https://en.wikipedia.org/wiki/Consensus_(computer_science)">consensus
protocol</a> to maintain a shared ledger in which each transaction is
cryptographically signed and chained to the previous transaction.
  </dd>



  <dt><dfn data-lt="">Delegate</dfn></dt>

  <dd>
An entity who creates a DID and associated DID document for a <a>dependent</a> who
does not yet have the capacity to control the private keys. The
dependent must rely on the delegate to safeguard the private keys until
the dependent can assume control as the DID subject.
  </dd>



  <dt><dfn data-lt="">Identity Owner</dfn></dt>

  <dd>
The natural person, party, organization, or thing whose
identity is represented by a <a>DID</a> and who directly controls the
private keys to control the <a>DID Document</a>.
(Note: this specification avoids the term "user" since a DID subject is not
always an individual person.)
  </dd>

  <dt><dfn data-lt="">JSON Pointer</dfn></dt>

  <dd>
JSON Pointer defines a string syntax for identifying a specific value
within a JavaScript Object Notation (JSON) document as defined in [[RFC6901]]
  </dd>

  <dt><dfn data-lt="">Key Description</dfn></dt>

  <dd>
A JSON object contained inside a DID Document that contains all
the metadata necessary to use a public key or verification key. A list
of standard key descriptions is included in
Appendix <a href="#standard-key-descriptions"></a>.
  </dd>



  <dt><dfn data-lt="service endpoints">Service Endpoint</dfn></dt>

  <dd>
A network address at which a service operates on
behalf of a DID subject. Examples of specific services include
discovery services, social networks, file storage services, and
verifiable claim repository services. Service endpoints may also be provided
by a generalized data interchange protocol such as
<a>Extensible Data Interchange</a>.
  </dd>



  <dt><dfn data-lt="">UUID</dfn></dt>

  <dd>
Universally Unique Identifier as specified by <a href=
  "https://www.ietf.org/rfc/rfc4122.txt">RFC 4122</a> .
  </dd>


  <dt><dfn data-lt="XDI">Extensible Data Interchange</dfn> (aka XDI)</dt>

  <dd>
A semantic
graph format and semantic data interchange protocol defined by the
  <a href="https://www.oasis-open.org/committees/xdi/">OASIS XDI Technical
Committee</a>.
  </dd>

  <dt><dfn data-lt="URI|URIs">URI</dfn></dt>
  <dd>
An identifier as defined by [[RFC3986]].
  </dd>

</dl>