Interface DidDhtCreateOptions<TKms>

Optionally specify that the DID Subject is also identified by one or more other DIDs or URIs.

A 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.

See

DID Core Specification, § Also Known As

Example

const did = await DidDht.create({
 options: {
  alsoKnownAs: 'did:example:123'
};
Copy

Optionally specify which DID (or DIDs) is authorized to make changes to the DID document.

A 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 (or DIDs) 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.

See

DID Core Specification, § DID Controller

Example

const did = await DidDht.create({
 options: {
  controller: 'did:example:123'
};
Copy

Optional. The URI of a server involved in executing DID method operations. In the context of DID creation, the endpoint is expected to be a DID DHT Gateway or Pkarr relay. If not specified, a default gateway node is used.

Optional. Determines whether the created DID should be published to the DHT network.

If set to true or omitted, the DID is publicly discoverable. If false, the DID is not published and cannot be resolved by others. By default, newly created DIDs are published.

See

DID DHT Method Specification

Example

const did = await DidDht.create({
 options: {
  publish: false
};
Copy

Optional. An array of service endpoints associated with the DID.

Services 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.

See

DID Core Specification, § Services

Example

const did = await DidDht.create({
 options: {
  services: [
    {
      id: 'did:dht:i9xkp8ddcbcg8jwq54ox699wuzxyifsqx4jru45zodqu453ksz6y#dwn',
      type: 'DecentralizedWebNode',
      serviceEndpoint: ['https://example.com/dwn1', 'https://example/dwn2']
    }
  ]
};
Copy

Optionally specify one or more registered DID DHT types to make the DID discovereable.

Type indexing is an OPTIONAL feature that enables DIDs to become discoverable. DIDs that wish to be discoverable and resolveable by type can include one or more types when publishing their DID document to a DID DHT Gateway.

The registered DID types are published in the DID DHT Registry.

Optional. An array of verification methods to be included in the DID document.

By default, a newly created DID DHT document will contain a single Ed25519 verification method, also known as the Identity Key. Additional verification methods can be added to the DID document using the verificationMethods property.

See

DID Core Specification, § Verification Methods

Example

const did = await DidDht.create({
 options: {
  verificationMethods: [
    {
      algorithm: 'Ed25519',
      purposes: ['authentication', 'assertionMethod']
    },
    {
      algorithm: 'Ed25519',
      id: 'dwn-sig',
      purposes: ['authentication', 'assertionMethod']
    }
  ]
};
Copy