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="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>binding</dfn></dt>
  <dd>A concrete mechanism through which a <a>client</a> invokes a <a>DID resolver</a>. This could be a <a>local binding</a> such as a local command line tool or library API, or a <a>remote binding</a> such as the <a href="#bindings-https">HTTP(S) binding</a>. See Section <a href="#resolver-architectures"></a>.</dd>

  <dt><dfn>client</dfn></dt>
  <dd>Software and/or hardware that invokes a <a>DID resolver</a> in order to execute the <a>DID resolution</a> and/or <a>DID URL dereferencing</a> algorithms. This invocation is done via a <a>binding</a>. The term <a>client</a> does not imply any specific network topology.</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="https://w3c.github.io/did-core/#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 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>.
  </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 method's">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="https://w3c.github.io/did-core/#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="https://w3c.github.io/did-core/#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="https://w3c.github.io/did-core/#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 <a href="#resolving"></a>.
  </dd>

  <dt><dfn data-lt="DID resolver's">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 resolution result</dfn></dt>
  <dd>A data structure that represents the result of the <a>DID resolution</a> algorithm.
    May contain a <a>DID document</a>. See Section <a href="#did-resolution-result"></a>.</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="https://w3c.github.io/did-core/#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="https://w3c.github.io/did-core/#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
    <a href="#dereferencing"></a>.
  </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="">DID URL dereferencing result</dfn></dt>
  <dd>A data structure that represents the result of the <a>DID URL dereferencing</a> algorithm.
    May contain a <a>DID document</a> or other content. See Section <a href="#did-url-dereferencing-result"></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 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="https://w3c.github.io/did-core/#representations"></a>.
  </dd>

  <dt><dfn data-lt="">local binding</dfn></dt>
  <dd>A <a>binding</a> where the <a>client</a> invokes a <a>DID resolver</a> that runs on the same network host, e.g., via a local command line tool or library API.
    In this case, the <a>DID resolver</a> is sometimes also called a "local <a>DID resolver</a>".
    See Section <a href="#resolver-architectures"></a>.</dd>

  <dt><dfn data-lt="">remote binding</dfn></dt>
  <dd>A <a>binding</a> where the <a>client</a> invokes a <a>DID resolver</a> that runs on a different network host, e.g., via the <a href="#bindings-https">HTTP(S) binding</a>.
    In this case, the <a>DID resolver</a> is sometimes also called a "remote <a>DID resolver</a>".
    See Section <a href="#resolver-architectures"></a>.</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="">service endpoint construction</dfn></dt>
  <dd>An algorithm that takes a <a>DID URL</a> and a service, and constructs
    a <a>service endpoint</a> URL See Section <a href="#service-endpoint-construction"></a>.</dd>

  <dt><dfn data-lt="">unverifiable read</dfn></dt>
  <dd> A low confidence implementation of a <a>DID method's</a> "Read" operation between the
    <a>DID resolver</a> and the <a>verifiable data registry</a>, to obtain the <a>DID document</a>.
    There is no guarantee about the integrity and correctness of the result. See Section <a href="#method-architectures"></a>.</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 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="">verifiable read</dfn></dt>
  <dd> A high confidence implementation of a <a>DID method's</a> "Read" operation between the
    <a>DID resolver</a> and the <a>verifiable data registry</a>, to obtain the <a>DID document</a>.
    There are guarantees about the integrity and correctness of the result to the extent possible under the applicable <a>DID method</a>.
    See Section <a href="#method-architectures"></a>.</dd>

</dl>