diff --git a/terms.html b/terms.html index b94ec7de..5fbe503d 100644 --- a/terms.html +++ b/terms.html @@ -1,33 +1,34 @@

-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: +This section defines the terms used in this specification and throughout +decentralized identifier infrastructure. A link to these terms is +included whenever they appear in this specification.

-
authentication
+
authentication
-Authentication is a mechanism by which an entity can prove it is the DID -subject, using one or more of a set of verification methods (such as, but -not limited to, public keys). +A process (typically some type of protocol) by which an entity can prove it has +a specific attribute or controls a specific secret using one or more +verification methods. With DIDs, a common example would be proving +control of the private key associated with a public key published in a +DID document.
blockchain
-A specific type of distributed ledger technology (DLT) that stores ledger -entries in blocks of transactions, which are grouped together and hashed into a -cryptographic chain. Because this type of DLT was introduced by -Bitcoin, the term -blockchain is sometimes used to refer specifically to the Bitcoin +A specific type of distributed ledger technology (DLT) in which ledger +entries are stored in blocks of transactions that are grouped together and +hashed into a cryptographic chain. Because this type of DLT was +introduced by Bitcoin, the +term blockchain is sometimes used to refer specifically to the Bitcoin ledger.
binding
-A concrete mechanism through which a caller invokes a DID resolver or a +A concrete mechanism used by a caller to invoke a DID resolver or a DID URL dereferencer. This could be a local command line tool, a software library, or a network call such as an HTTPS request.
@@ -35,169 +36,174 @@
decentralized identifier (DID)
-A globally unique identifier that does not require a centralized registration -authority because it is registered with distributed ledger technology -(DLT) or other form of decentralized network. The generic format of a DID is -defined in the DID Core specification. +A globally unique persistent identifier that does not require a centralized +registration authority because it is generated and/or registered cryptographically. +The generic format of a DID is defined in the +DID Core specification. A specific DID scheme is defined in a DID method specification. +Many—but not all—DID methods make use of distributed ledger technology +(DLT) or some other form of decentralized network.
decentralized identity management
-Identity -management based on decentralized identifiers. Decentralized identity -management extends the identifier creation authority beyond the traditional -roots of trust required by +identity +management that is based on the use of decentralized identifiers. +Decentralized identity management extends authority for identifier generation, +registration, and assignment beyond traditional roots of trust such as X.500 directory services, the Domain Name System, -and most national identification systems. +and most national ID systems.
decentralized public key infrastructure (DPKI)
-Public key infrastructure based on decentralized identifiers and identity -records (for example, DID documents) containing verifiable -public key descriptions. + Public key infrastructure + that does not rely on traditional certificate authorities because it uses decentralized identifiers and +DID documents) to discover and verify public key descriptions.
DID controller
-The entity that has the ability to make changes to a DID document. -A DID can have more than one controller. The DID controller(s) -are denoted by the `controller` property on the top level of the DID -document. Note that the DID controller(s) might include the -DID subject. +An entity that has the capability to make changes to a DID document. +A DID may have more than one DID controller. The DID controller(s) +can be denoted by the optional `controller` property at the top level of the DID +document. Note that one DID controller may be the DID subject.
DID delegate
-An entity that the DID controller has approved to use cryptographic -material associated with the DID document. For example, a parent -that controls a child's DID document might approve the child -to use their personal device for authentication purposes. In this case, the -child is the DID delegate 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. +An entity to whom a DID controller has granted permission to use +a verification method associated with a DID via a DID document. +For example, a parent who controls a child's DID document might permit +the child to use their personal device for authentication purposes. In +this case, the child is the DID delegate. The child's personal device +would contain the private cryptographic material enabling the child to +authenticate using the DID. However the child may not be permitted to +add other personal devices without the parent's permission.
DID document
A set of data describing the DID subject, 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 might also contain other +public keys and pseudonymous biometrics, that the DID subject or a +DID delegate can use to authenticate itself and prove its +association with the DID. A DID document may also contain other attributes or claims -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. +describing the DID subject. A DID document may have one or more different +representations as defined in or in +the W3C DID Specification Registries [[DID-SPEC-REGISTRIES]].
DID fragment
The portion of a DID URL that follows the first hash sign character -(#). DID fragment syntax is identical to the URI fragment syntax. +(#). DID fragment syntax is identical to URI fragment syntax.
DID method
-A definition of how a specific DID scheme can be implemented on a -specific verifiable data registry, including the precise methods by -which DIDs are resolved and deactivated and DID documents are -written and updated. +A definition of how a specific DID scheme must be implemented to work +with a specific verifiable data registry. A DID method is defined by a +DID method specification, which must specify the precise operations by which +DIDs are created, resolved and deactivated and DID documents are +written and updated. See .
DID path
The portion of a DID URL that begins with and includes the first forward -slash character (/). DID path syntax is identical to the URI path -syntax. +slash (/) character and ends with either a question mark (?) +character or a fragment hash sign (#) character (or the end of the +DID URL). DID path syntax is identical to URI path syntax. See +.
DID query
-The portion of a DID URL that follows the first question mark character -(?). DID query syntax is identical to the URI query syntax. -
- -
Verifiable - data registry
- -
-A role a system performs to mediate the creation, verification, updating, and -deactivation of decentralized identifiers. For more information, see -[[VC-DATA-MODEL]]. +The portion of a DID URL that follows and includes the first question +mark character (?). DID query syntax is identical to URI query +syntax. See .
DID resolution
The function that takes as its input a DID and a set of input -metadata and returns a DID document in a conforming representation +metadata and returns a DID document in a conforming representation plus additional metadata. This function relies on the "Read" operation of the -applicable DID method. The inputs and outputs of this function are defined -in . +applicable DID method. The inputs and outputs of this function are +defined in .
DID resolver
-A DID resolver is a software and/or hardware component that takes -a DID as input and produces a conforming DID document as -output by performing DID resolution. +A DID resolver is a software and/or hardware component that performs the +DID resolution function by taking a DID as input and producing a +conforming DID document as output.
DID scheme
The formal syntax of a decentralized identifier. The generic DID scheme -is defined in the DID Core specification. -Separate DID method specifications define a specific DID scheme that -works with that specific DID method. +begins with the prefix did: as defined in the +section of the DID Core specification. +Each DID method specification must define a specific DID +scheme that works with that specific DID method. In a specific DID method +scheme, the DID method name must follow the first colon and terminate with the +second colon, e.g., did:example:
DID subject
-The entity the DID document is about. That is, the entity identified by -the DID and described by the DID document. +The entity identified by a DID and described by a DID document. A +DID has exactly one DID subject. Anything can be a DID subject: person, +group, organization, physical thing, digital thing, logical thing, etc.
DID URL
-A DID plus an optional DID path, optional ? character -followed by a DID query, and optional # character followed -by a DID fragment. +A DID plus any additional syntactic component that conforms to the +definition in . This includes an optional DID path, +optional DID query (and its leading ? character), and +optional DID fragment (and its leading # character).
DID URL dereferencing
The function that takes as its input a DID URL, a DID document, -and a set of dereferencing options and returns a resource, which might be -a DID document, plus additional metadata. This function can use the DID resolution -function to fetch a DID document indicated by the DID within the DID URL. -The dereferencing function then can perform additional processing on the DID document to return -the dereferenced resource indicated by the DID URL. The inputs and outputs of this -process are defined in . +plus a set of dereferencing options, and returns a resource. This +resource may be a DID document plus additional metadata, or it may be a +secondary resource contained within the DID document, or it may be a +resource entirely external to the DID document. If the function begins +with a DID URL, it use the DID resolution function to fetch a +DID document indicated by the DID contained within the +DID URL. The dereferencing function then can perform additional +processing on the DID document to return the dereferenced resource +indicated by the DID URL. The inputs and outputs of this function are +defined in .
DID URL dereferencer
-A software and/or hardware system that is capable of executing the DID URL dereferencing -function, retrieving some form of data, which might or might not be a DID document) for a given -DID URL by performing DID URL dereferencing. +A software and/or hardware system that performs the DID URL dereferencing +function for a given DID URL or DID document.
distributed ledger (DLT)
@@ -210,96 +216,109 @@ signed and chained to the previous transaction. -
extensible data interchange (XDI)
+
proof purpose
-A semantic graph format and semantic data interchange protocol defined by the -OASIS XDI Technical Committee. +A property of a DID document that communicates the purpose for which the +DID controller included a specific type of proof. It acts as a safeguard +to prevent the proof from being misused for a purpose other than the one it was +intended for.
-
identity owner
+
public key description
-The natural person, party, organization, or thing whose identity is represented -by a DID and who directly controls the private keys to control the -DID document. Note that this specification avoids the term user -since a DID subject is not always an individual person. +A data object contained inside a DID document that contains all the +metadata necessary to use a public key or verification key.
-
proof purpose
+
resource
-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. +As defined by [[RFC3986]]: "...the term 'resource' is used in a general sense +for whatever might be identified by a URI." Similarly, any resource may serve as +a DID subject identified by a DID.
-
public key description
+
representation
-A JSON object contained inside a DID document that contains all the -metadata necessary to use a public key or verification key. +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 DID document is a representation of information +describing a DID subject. The +section of the DID Core specification +defines several representation formats for a DID document. +
+ +
service
+
+A means of communicating or interacting with the DID subject or +associated entities via one or more service endpoints. +Examples include discovery services, agent services, social networking +services, file storage services, and verifiable credential repository services.
-
resource
+
service endpoint
-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. -The DID Core 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 DID. +A network address (such as an HTTP URL) at which a service operates on +behalf of a DID subject.
-
service
+
Uniform Resource Identifier (URI)
+
-Services provide ways of communicating or interacting with the DID -subject or associated entities. Examples of specific services include -discovery services, social networks, file storage services, and verifiable -claim repository services. +The standard identifier format for all resources on the World Wide Web as +defined by [[RFC3986]]. A DID is a type of URI scheme.
-
service endpoint
+
verifiable credential
-A network address at which a service operates on behalf of a DID -subject. Service endpoints might also be provided by a generalized data -interchange protocol, such as extensible data interchange. +A standard data model and representation format for cryptographically-verifiable +digital credentials as defined by the W3C [[VC-DATA-MODEL]].
-
Uniform Resource Identifier (URI)
+
verifiable + data registry
-An identifier, as defined by [[RFC3986]]. +A system that facilitates the creation, verification, updating, and/or +deactivation of decentralized identifiers and DID documents. A +verifiable data registry may also be used for other cryptographically-verifiable +data structures such as verifiable credentials. For more information, see +[[VC-DATA-MODEL]].
verifiable timestamp
-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. +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 modified or corrupted since that moment in time, the timestamp is not +verifiable.
verification method

-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. +A set of parameters that can be used together with a process or protocol to +independently verify a proof. 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.

-"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." +"Verification" and "proof" in this definition are intended to apply broadly. For +example, 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" +or "proof."

@@ -307,16 +326,19 @@

-A verification relationship expresses the relationship between the DID -subject and a verification method. An example of a verification -relationship is . +An expression of the relationship between the DID subject and a +verification method. An example of a verification relationship is +.

Universally Unique Identifier (UUID)
-An identifier, as defined by [[RFC4122]]. +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.