terms.html

<p>
This section defines the terms used in this specification and throughout
<a>decentralized identifier</a> infrastructure. A link to these terms is
included whenever they appear in this specification.
</p>

<dl class="termlist">

  <dt><dfn data-lt="amplification">amplification attack</dfn></dt>
  <dd>
A class of attack where the attacker attempts to exhaust a target system's
CPU, storage, network, or other resources by providing small, valid inputs into
the system that result in damaging effects that can be exponentially more costly
to process than the inputs themselves.
  </dd>

  <dt><dfn data-lt="authenticated">authenticate</dfn></dt>
  <dd>
Authentication is a process by which an entity can prove it has a specific
attribute or controls a specific secret using one or more <a>verification
methods</a>. With <a>DIDs</a>, a common example would be proving control of the
cryptographic private key associated with a public key published in a <a>DID
document</a>.
  </dd>

  <dt><dfn class="lint-ignore">binding</dfn></dt>
  <dd>
A concrete mechanism used by a caller to invoke a <a>DID resolver</a> or a
<a>DID URL dereferencer</a>. This could be a local command line tool, a software
library, or a network call such as an HTTPS request.
  </dd>

  <dt><dfn data-lt="cryptosuite">cryptographic suite</dfn></dt>
  <dd>
A specification defining the usage of specific cryptographic primitives in
order to achieve a particular security goal. These documents are often used
to specify <a>verification methods</a>, digital signature types,
their identifiers, and other related properties.
  </dd>

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

  <dd>
A globally unique persistent identifier that does not require a centralized
registration authority and is often generated and/or registered
cryptographically. The generic format of a DID is defined in <a
href="#did-syntax"></a>. A specific <a>DID scheme</a> is defined in a <a>DID
method</a> specification. Many—but not all—DID methods make use of
<a>distributed ledger technology</a> (DLT) or some other form of decentralized
network.
  </dd>

  <dt><dfn>decentralized identity management</dfn></dt>

  <dd>
<a href="https://en.wikipedia.org/wiki/Identity_management">Identity
management</a> that is based on the use of <a>decentralized identifiers</a>.
Decentralized identity management extends authority for identifier generation,
registration, and assignment beyond traditional roots of trust such as
<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 class="lint-ignore">decentralized public key infrastructure</dfn> (DPKI)</dt>

  <dd>
<a href="https://en.wikipedia.org/wiki/Public_key_infrastructure">Public key
infrastructure</a> that does not rely on traditional <a
href="https://en.wikipedia.org/wiki/Certificate_authority">certificate
authorities</a> because it uses <a>decentralized identifiers</a> and <a>DID
documents</a> to discover and verify <a>public key descriptions</a>.
  </dd>

  <dt><dfn data-lt="did controllers|did controller(s)">DID controller</dfn></dt>

  <dd>
An entity that has the capability to make changes to a <a>DID document</a>. A
<a>DID</a> might have more than one DID controller. The DID controller(s)
can be denoted by the optional `controller` property at the top level of the
<a>DID document</a>. Note that a DID controller might be the <a>DID
subject</a>.
  </dd>

  <dt><dfn>DID delegate</dfn></dt>

  <dd>
An entity to whom a <a>DID controller</a> has granted permission to use a
<a>verification method</a> associated with a <a>DID</a> via a <a>DID
document</a>. For example, a parent who controls a child's <a>DID document</a>
might permit the child to use their personal device in order to
<a>authenticate</a>. In this case, the child is the <a>DID delegate</a>. The
child's personal device would contain the private cryptographic material
enabling the child to <a>authenticate</a> using the <a>DID</a>. However, the child
might not be permitted to add other personal devices without the parent's
permission.
  </dd>

  <dt><dfn data-lt="DID documents">DID document</dfn></dt>

  <dd>
A set of data describing the <a>DID subject</a>, including mechanisms, such as
cryptographic public keys, that the <a>DID subject</a> or a <a>DID delegate</a>
can use to <a>authenticate</a> itself and prove its association with the
<a>DID</a>. A DID document might have one or more different
<a>representations</a> as defined in <a href="#representations"></a> or in the
W3C DID Specification Registries [[DID-SPEC-REGISTRIES]].
  </dd>

  <dt><dfn data-lt="DID fragments">DID fragment</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that follows the first hash sign character
(<code>#</code>). DID fragment syntax is identical to URI fragment syntax.
  </dd>

  <dt><dfn data-lt="DID methods">DID method</dfn></dt>

  <dd>
A definition of how a specific <a>DID method scheme</a> is implemented. A DID method is
defined by a DID method specification, which specifies the precise operations by
which <a>DIDs</a> and <a>DID documents</a> are created, resolved, updated,
and deactivated. See <a href="#methods"></a>.
  </dd>

  <dt><dfn data-lt="DID paths">DID path</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that begins with and includes the first forward
slash (<code>/</code>) character and ends with either a question mark
(<code>?</code>) character, a fragment hash sign (<code>#</code>) character,
or the end of the <a>DID URL</a>. DID path syntax is identical to URI path syntax.
See <a href="#path"></a>.
  </dd>

  <dt><dfn data-lt="DID queries">DID query</dfn></dt>

  <dd>
The portion of a <a>DID URL</a> that follows and includes the first question
mark character (<code>?</code>). DID query syntax is identical to URI query
syntax. See <a href="#query"></a>.
  </dd>

  <dt><dfn>DID resolution</dfn></dt>

  <dd>
The process that takes as its input a <a>DID</a> and a set of resolution
options and returns a <a>DID document</a> in a conforming <a>representation</a>
plus additional metadata. This process relies on the "Read" operation of the
applicable <a>DID method</a>. The inputs and outputs of this process are
defined in [[?DID-RESOLUTION]].
  </dd>

  <dt><dfn data-lt="DID resolvers">DID resolver</dfn></dt>

  <dd>
A <a>DID resolver</a> is a software and/or hardware component that performs the
<a>DID resolution</a> function by taking a <a>DID</a> as input and producing a
conforming <a>DID document</a> as output.
  </dd>

  <dt><dfn data-lt="DID schemes|DID method scheme">DID scheme</dfn></dt>

  <dd>
The formal syntax of a <a>decentralized identifier</a>. The generic DID scheme
begins with the prefix <code>did:</code> as defined in <a
href="#did-syntax"></a>. Each <a>DID method</a> specification defines a specific
DID method scheme that works with that specific <a>DID method</a>. In a specific DID
method scheme, the DID method name follows the first colon and terminates with
the second colon, e.g., <code>did:example:</code>
  </dd>

  <dt><dfn data-lt="DID subjects">DID subject</dfn></dt>

  <dd>
The entity identified by a <a>DID</a> and described by a <a>DID document</a>.
Anything can be a DID subject: person, group, organization, physical thing,
digital thing, logical thing, etc.
  </dd>

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

  <dd>
A <a>DID</a> plus any additional syntactic component that conforms to the
definition in <a href="#did-url-syntax"></a>. This includes an optional <a>DID
path</a> (with its leading <code>/</code> character), optional <a>DID query</a>
(with its leading <code>?</code> character), and optional <a>DID fragment</a>
(with its leading <code>#</code> character).
  </dd>

  <dt><dfn>DID URL dereferencing</dfn></dt>

  <dd>
The process that takes as its input a <a>DID URL</a> and a set of input
metadata, and returns a <a>resource</a>. This resource might be a <a>DID
document</a> plus additional metadata, a secondary resource
contained within the <a>DID document</a>, or a resource entirely
external to the <a>DID document</a>. The process uses <a>DID resolution</a> to
fetch a <a>DID document</a> indicated by the <a>DID</a> contained within the
<a>DID URL</a>. The dereferencing process can then perform additional processing
on the <a>DID document</a> to return the dereferenced resource indicated by the
<a>DID URL</a>. The inputs and outputs of this process are defined in
[[?DID-RESOLUTION]].
  </dd>

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

  <dd>
A software and/or hardware system that performs the <a>DID URL dereferencing</a>
function for a given <a>DID URL</a> or <a>DID document</a>.
  </dd>

  <dt><dfn data-lt="distributed ledger technology|DLT">distributed ledger</dfn> (DLT)</dt>

  <dd>
A non-centralized system for recording events. These systems establish
sufficient confidence for participants to rely upon the data recorded by others
to make operational decisions. They typically use distributed databases where
different nodes use a consensus protocol to confirm the ordering of
cryptographically signed transactions. The linking of digitally signed
transactions over time often makes the history of the ledger effectively
immutable.
  </dd>

  <dt><dfn>public key description</dfn></dt>

  <dd>
A data object contained inside a <a>DID document</a> that contains all the
metadata necessary to use a public key or a verification key.
  </dd>

  <dt><dfn data-lt="resources">resource</dfn></dt>

  <dd>
As defined by [[RFC3986]]: "...the term 'resource' is used in a general sense
for whatever might be identified by a URI." Similarly, any resource might serve
as a <a>DID subject</a> identified by a <a>DID</a>.
  </dd>

    <dt><dfn data-lt="representations">representation</dfn></dt>

  <dd>
As defined for HTTP by [[RFC7231]]: "information that is intended to reflect a
past, current, or desired state of a given resource, in a format that can be
readily communicated via the protocol, and that consists of a set of
representation metadata and a potentially unbounded stream of representation
data." A <a>DID document</a> is a representation of information describing a
<a>DID subject</a>. See <a href="#representations"></a>.
  </dd>

    <dt><dfn data-lt="representation-specific entry|non-representation-specific
entry">representation-specific entries</dfn></dt>

  <dd>
Entries in a <a>DID document</a> whose meaning is particular to a specific
<a>representation</a>. Defined in <a href="#data-model"></a> and
<a href="#representations"></a>. For example, <a><code>@context</code></a> in
the <a href="#json-ld">JSON-LD representation</a> is a
<em>representation-specific entry</em>.
  </dd>

  <dt><dfn data-lt="service">services</dfn></dt>
  <dd>
Means of communicating or interacting with the <a>DID subject</a> or
associated entities via one or more <a>service endpoints</a>.
Examples include discovery services, agent services, social networking
services, file storage services, and verifiable credential repository services.
  </dd>

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

  <dd>
A network address, such as an HTTP URL, at which <a>services</a> operate on
behalf of a <a>DID subject</a>.
  </dd>

  <dt><dfn data-lt="URI|URIs">Uniform Resource Identifier</dfn> (URI)</dt>

  <dd>
The standard identifier format for all resources on the World Wide Web as
defined by [[RFC3986]]. A <a>DID</a> is a type of URI scheme.
  </dd>

    <dt><dfn data-lt="verifiable credentials">verifiable credential</dfn></dt>

  <dd>
A standard data model and representation format for cryptographically-verifiable
digital credentials as defined by the W3C Verifiable Credentials specification
[[VC-DATA-MODEL]].
  </dd>

  <dt>
    <dfn data-lt="verifiable data registry|verifiable data registries">
    verifiable data registry</dfn>
  </dt>

  <dd>
A system that facilitates the creation, verification, updating, and/or
deactivation of <a>decentralized identifiers</a> and <a>DID documents</a>. A
verifiable data registry might also be used for other
cryptographically-verifiable data structures such as <a>verifiable
credentials</a>. For more information, see the W3C Verifiable Credentials
specification [[VC-DATA-MODEL]].
  </dd>

  <dt><dfn>verifiable timestamp</dfn></dt>

  <dd>
A verifiable timestamp enables a third-party to verify that a data object
existed at a specific moment in time and that it has not been modified or
corrupted since that moment in time. If the data integrity could reasonably have
been modified or corrupted since that moment in time, the timestamp is not
verifiable.
  </dd>

  <dt><dfn data-lt="">verification method</dfn></dt>

  <dd>
    <p>
A set of parameters that can be used together with a process to independently
verify a proof. For example, a cryptographic public key can be used as a
verification method with respect to a digital signature; in such usage, it
verifies that the signer possessed the associated cryptographic private key.
    </p>
    <p>
"Verification" and "proof" in this definition are intended to apply broadly. For
example, a cryptographic public key might be used during Diffie-Hellman key
exchange to negotiate a shared symmetric key for encryption. This guarantees the
integrity of the key agreement process. It is thus another type of verification
method, even though descriptions of the process might not use the words
"verification" or "proof."
    </p>
  </dd>

  <dt><dfn data-lt="">verification relationship</dfn></dt>

  <dd>
    <p>
An expression of the relationship between the <a>DID subject</a> and a
<a>verification method</a>. An example of a verification relationship is
<a href="#authentication"></a>.
    </p>
  </dd>

  <dt><dfn data-lt="UUID|UUIDs">Universally Unique Identifier</dfn> (UUID)</dt>

  <dd>
A type of globally unique identifier defined by [[RFC4122]]. UUIDs are similar
to DIDs in that they do not require a centralized registration authority. UUIDs
differ from DIDs in that they are not resolvable or
cryptographically-verifiable.
  </dd>

</dl>