pub struct Document {
pub context: Vec<Kind<Value>>,
pub id: String,
pub also_known_as: Option<Vec<String>>,
pub controller: Option<Quota<String>>,
pub service: Option<Vec<Service>>,
pub verification_method: Option<Vec<VerificationMethod>>,
pub authentication: Option<Vec<Kind<VerificationMethod>>>,
pub assertion_method: Option<Vec<Kind<VerificationMethod>>>,
pub key_agreement: Option<Vec<Kind<VerificationMethod>>>,
pub capability_invocation: Option<Vec<Kind<VerificationMethod>>>,
pub capability_delegation: Option<Vec<Kind<VerificationMethod>>>,
pub did_document_metadata: Option<DocumentMetadata>,
}Expand description
DID Document
Fields§
§context: Vec<Kind<Value>>The context of the DID document.
id: StringThe DID for a particular DID subject.
The subject is defined as the entity identified by the DID and described by the DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
also_known_as: Option<Vec<String>>A set of URIs taht are other identifiers for the subject of the above DID.
controller: Option<Quota<String>>One or more strings that conform to the rules DID Syntax. The corresponding DID document(s) SHOULD contain verification relationships that explicitly permit the use of certain verification methods for specific purposes.
Any verification methods contained in the related DID documents SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are to be considered equivalent to proofs provided by the DID subject.
service: Option<Vec<Service>>A set of services, that express ways of communicating with the DID subject or related entities.
verification_method: Option<Vec<VerificationMethod>>If set, MUST be a set of verification methods for the DID subject.
authentication: Option<Vec<Kind<VerificationMethod>>>The 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 in any sort of challenge-response
protocol.
assertion_method: Option<Vec<Kind<VerificationMethod>>>The assertion_method 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.
key_agreement: Option<Vec<Kind<VerificationMethod>>>The key_agreement 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.
capability_invocation: Option<Vec<Kind<VerificationMethod>>>The capability_invocation 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.
capability_delegation: Option<Vec<Kind<VerificationMethod>>>The capability_delegation 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.
did_document_metadata: Option<DocumentMetadata>If resolution is successful, this MUST be metadata about the DID document. This typically does not change between invocations of the resolve and resolveRepresentation functions unless the DID document changes. If resolution is unsuccessful, this output MUST be an empty.