jspωiki
DID Document

Overview#

DID Document is an digital Distributed Identity Document

W3C Decentralized Identifiers#

DID Document is a set of data that describes a Decentralized Identifier, including mechanisms, such as Public Keys and pseudonymous biometrics, that an entity can use to authenticate itself as the W3C Decentralized Identifiers. A DID Document may also contain other attributes or claims describing the entity. 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.

DID Document is a component of the W3C Decentralized Identifiers and is the resource to which the DID URI

The combination of a DID Document and its associated DID Document forms the root record for a Decentralized Identifier.

DID Document MUST be a single JSON Object conforming to RFC 7159. For purposes of this version of the DID specification, the format of this JSON Object is specified in JSON-LD, a format for mapping JSON data into the RDF semantic graph model as defined by JSON-LD. Future versions of this specification MAY specify other semantic graph formats for a DID Document such as JXD (JSON XDI Data), a serialization format for the XDI graph model.

The following sections define the properties of this DID Document, including whether these properties are required or optional.

  • DID Context
  • DID Subject
  • Public Keys - lists public keys whose corresponding private keys are controlled by the entity identified by the DID ("owned" public keys). However, a DID Document MAY also list "non-owned" public keys.
    • MAY include a publicKey property.
    • The value of the publicKey property should be an array of Public Keys.
    • MUST include id and type properties, and exactly one value property.
    • MAY include an owner property, which identifies the entity that controls the corresponding Private Key. If this property is missing, it is assumed to be the DID Subject.
    • The value property of a public key MAY be publicKeyPem, publicKeyJwk, publicKeyHex, publicKeyBase64 or similar, depending on the format and encoding of the Public Key. A registry of key types and formats is available in Appendix A. Registries .
  • DID Authentication
  • Authorization and Delegation - Since Authorization and Delegation are typically implemented by the underlying Distributed Ledger Technology, each DID Method specification is expected to detail how authorization and delegation are performed for the Distributed Ledger Technology.
  • Service Endpoints
    • MAY include a service property.
    • The value of the service property should be an array of service endpoints.
    • MUST include id, type, and serviceEndpoint properties, and MAY include additional properties.
    • protocol SHOULD be published in an open standard specification.
    • The value of the serviceEndpoint property MUST be a JSON-LD object or a valid URI conforming to RFC 3986 and normalized according to the rules in section 6 of RFC 3986 and to any normalization rules in its applicable URI scheme specification.
  • Created
    • MAY have one property representing a creation timestamp. It is RECOMMENDED to include this property.
    • The key for this property MUST be created.
    • The value of this key MUST be a valid XML DateTime value as defined in section 3.3.7 of W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes XMLSCHEMA11-2.
    • This datetime value MUST be normalized to UTC 00:00 as indicated by the trailing "Z".
    • Method specifications that rely on DLTs SHOULD require time values that are after the known "median time past" (defined in Bitcoin BIP 113), when the DLT supports such a notion.
  • Updated
    • MAY have one property representing a creation timestamp. It is RECOMMENDED to include this property.
    • The key for this property MUST be created.
    • The value of this key MUST be a valid XML DateTime value as defined in section 3.3.7 of W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes XMLSCHEMA11-2.
    • This datetime value MUST be normalized to UTC 00:00 as indicated by the trailing "Z".
    • Method specifications that rely on DLTs SHOULD require time values that are after the known "median time past" (defined in Bitcoin BIP 113), when the DLT supports such a notion.
  • Proof

More Information#

There might be more information for this subject on one of the following: