Optional @contextA JSON-LD context link, which provides a JSON-LD processor with the information necessary to interpret the DID document JSON. The default context URL is 'https://www.w3.org/ns/did/v1'.
Optional alsoA DID subject can have multiple identifiers for different purposes, or at different times.
The assertion that two or more DIDs (or other types of URI) refer to the same DID subject can
be made using the alsoKnownAs property.
Optional assertionThe assertionMethod verification relationship is used to specify how the DID subject is
expected to express claims, such as for the purposes of issuing a Verifiable Credential.
Optional authenticationThe authentication verification relationship is used to specify how the DID subject is expected
to be authenticated, for purposes such as logging into a website or engaging in any sort of
challenge-response protocol.
Optional capabilityThe capabilityDelegation verification relationship is used to specify a mechanism that might
be used by the DID subject to delegate a cryptographic capability to another party, such as
delegating the authority to access a specific HTTP API to a subordinate.
Optional capabilityThe capabilityInvocation verification relationship is used to specify a verification method
that might be used by the DID subject to invoke a cryptographic capability, such as the
authorization to update the DID Document.
Optional controllerA DID controller is an entity that is authorized to make changes to a DID document. Typically,
only the DID Subject (i.e., the value of id property in the DID document) is authoritative.
However, another DID can be specified as the DID controller, and when doing so, any
verification methods contained in the DID document for the other DID should be accepted as
authoritative. In other words, proofs created by the controller DID should be considered
equivalent to proofs created by the DID Subject.
The DID Subject to which this DID Document pertains.
The id property is REQUIRED and must be a valid DID.
Optional keyThe keyAgreement verification relationship is used to specify how an entity can generate
encryption material in order to transmit confidential information intended for the DID
subject, such as for the purposes of establishing a secure communication channel with the
recipient.
Optional serviceServices are used in DID documents to express ways of communicating with the DID subject or associated entities. A service can be any type of service the DID subject wants to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction.
Optional verificationA DID document can express verification methods, such as cryptographic public keys, which can be used to authenticate or authorize interactions with the DID subject or associated parties.
A set of data describing the Decentralized Identifierr (DID) subject.
A DID Document contains information associated with the DID, such as cryptographic public keys and service endpoints, enabling trustable interactions associated with the DID subject.
A DID Document can be retrieved by resolving a DID, as described in DID Core Specification, § DID Resolution.