terms.html

<p>
This document attempts to communicate the concepts outlined in the
<a>decentralized identifier</a> 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="blockchains|blockchain technology">blockchain</dfn></dt>

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

  <dt><dfn>binding</dfn></dt>
  <dd>
A concrete mechanism through which a caller invokes 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="decentralized identifiers|DID|DIDs">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 technology</a>
(DLT) 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>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 identification systems.
  </dd>

  <dt><dfn>decentralized public key infrastructure</dfn> (DPKI)</dt>

  <dd>
Public key infrastructure based on <a>decentralized identifiers</a> and identity
records (for example, <a>DID documents</a>) containing verifiable
<a>public key descriptions</a>.
  </dd>

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

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

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

  <dd>
An entity that the <a>DID controller</a> has approved to use cryptographic
material associated with the <a>DID document</a>. For example, a parent
that controls a child's <a>DID document</a> might approve the child
to use their personal device for authentication purposes. In this case, the
child is the <a>DID delegate</a> and their personal device contains
private cryptographic material to enable the child to authenticate as the DID,
but not to add new personal devices without the parent's approval.
  </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
public keys and pseudonymous biometrics, that the <a>DID subject</a> can use to
authenticate itself and prove their association with the <a>DID</a>. A DID
document might 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 can be expressed using other
compatible graph-based data formats.
  </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 the URI fragment syntax.
  </dd>

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

  <dd>
A definition of how a specific <a>DID scheme</a> can be implemented on a
specific <a>distributed ledger</a> or network, including the precise methods by
which <a>DIDs</a> are resolved and deactivated and <a>DID documents</a> are
written and updated.
  </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 character (<code>/</code>). DID path syntax is identical to the URI path
syntax.
  </dd>

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

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

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

  <dd>
A role a system performs to mediate the creation, verification, updating, and
deactivation of <a>decentralized identifiers</a>. For more information, see
[[VC-DATA-MODEL]].
  </dd>

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

  <dd>
The function that takes as its input a <a>DID</a> and a set of input
metadata and returns a <a>DID document</a> in a conforming representation
plus additional metadata. This function relies on the "Read" operation of the
applicable <a>DID method</a>. The inputs and outputs of this function are defined
in <a href="#did-resolution"></a>.
  </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 takes
a <a>DID</a> as input and produces a <a>conforming DID document</a> as
output by performing <a>DID resolution</a>.
  </dd>

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

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

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

  <dd>
The entity the <a>DID document</a> is about. That is, the entity identified by
the <a>DID</a> and described by the <a>DID document</a>.
  </dd>

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

  <dd>
A <a>DID</a> 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>DID URL dereferencing</dfn></dt>

  <dd>
The function that takes as its input a <a>DID URL</a>, a <a>DID document</a>,
and a set of dereferencing options and returns a resource, which might be
a <a>DID document</a>, plus additional metadata. This function can use the <a>DID resolution</a>
function to fetch a <a>DID document</a> indicated by the <a>DID</a> within the <a>DID URL</a>.
The dereferencing function then can 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 <a href="#did-url-dereferencing"></a>.
  </dd>

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

  <dd>
A software and/or hardware system that is capable of executing the <a>DID URL dereferencing</a>
function, retrieving some form of data, which might or might not be a <a>DID document</a>) for a given
<a>DID URL</a> by performing <a>DID URL dereferencing</a>.
  </dd>

  <dt><dfn data-lt="distributed ledger technology|DLT">distributed ledger</dfn> (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="XDI">extensible data interchange</dfn> (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="identity owners">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 that this specification avoids the term <em>user</em>
since a <a>DID subject</a> is not always an individual person.
  </dd>

  <dt><dfn data-lt="proofPurpose">proof purpose</dfn></dt>

  <dd>
The specific intent for a proof, the reason why an entity created it.
Acts as a safeguard to prevent the proof from being misused for a purpose
other than the one it was intended for.
  </dd>

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

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

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

  <dd>
The term resource is used in the same way as defined for HTTP in [[RFC7231]];
that is, a resource is the target of a request and is identified by a URI.
This specification does not limit the nature of a resource, but defines an
interface that might be used to interact with resources when identified by
a <a>DID</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 <a>DID subject</a>.
Examples of specific services include discovery services, social networks, file
storage services, and verifiable claim repository services. Service endpoints
might also be provided by a generalized data interchange protocol, such as
<a>extensible data interchange</a>.
  </dd>

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

  <dd>
An identifier, as defined by [[RFC3986]].
  </dd>

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

  <dd>
A timestamp is verifiable if a third-party can confirm that a piece of data
existed at a specific moment in time. Verifying data integrity can be done in
such a way that the party verifying the data is highly confident that an
authority or malicious party could not have reasonably modified the data as it
existed at the attested moment in time. If the data integrity could reasonably
be modified or corrupted by a central authority or other party, the timestamp is
not verifiable.
  </dd>

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

  <dd>
    <p>
A set of parameters that can be used to independently verify a proof according to
a particular method. For example, a 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 private key.
    </p>
    <p>
"Verification" and "proof" in this definition are intended to apply broadly. A 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" and "proof."
    </p>
  </dd>

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

  <dd>
    <p>
A verification relationship expresses 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>
An identifier, as defined by [[RFC4122]].
  </dd>

</dl>