Resolve an IOTA Identity

DID resolution is the process of fetching a DID Document corresponding to a given DID. The IOTA Identity Framework supports resolving DID Documents that are stored on an IOTA Tangle (public or private). The main tool supplied by the IOTA Identity Framework to handle DID Document resolution in a type safe manner is the Resolver. A DID Resolver as defined in the W3C Decentralized Identifiers specification enforces the signature of the resolution function in a manner that is more centered around Web/API resolution rather than a strongly typed framework. This is the reason why the Resolver provided by the IOTA Identity Framework deviates somewhat from the W3C specification.

Resolving a DID from the main network

The following example demonstrates how to resolve the DID: "did:iota:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV" from the main network.

Rust

use identity_iota::client::Resolver;
use identity_iota::iota_core::IotaDID;
use identity_iota::client::ResolvedIotaDocument;

let resolver: Resolver = Resolver::new().await?;
let did: IotaDID = IotaDID::parse("did:iota:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV")?;

let doc: ResolvedIotaDocument = resolver.resolve(&did).await?;

Node.js

const { DID, Resolver, ResolvedDocument } = require('@iota/identity-wasm/node');

const resolver = new Resolver();
const did = DID.parse('did:iota:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV');
const doc = await resolver.resolve(did);

What happens in this example can be explained on a high level as follows: The Resolver queries the Tangle for the history of the DID Document and utilizes it to recreate and validate the latest state of the DID Document.

Resolving from a private tangle

Resolving a DID from a private tangle is similar to resolving a DID from the main net. The only difference is that the resolver needs to be configured to have a client capable of operating on said private tangle. Building a Client configured for a specified Tangle is explained in this example in Rust and this example in Javascript.

The following example demonstrates how one can setup a Resolver with a given client and then attempt resolving a specified did which may be on any Tangle (public or private).

Rust

use identity_iota::client::Resolver;
use identity_iota::client::ResolverBuilder;
use identity_iota::iota_core::IotaDID;
use identity_iota::client::Client;
use identity_iota::client::Result;


async fn build_and_resolve(client: Client, did: IotaDID) -> Result<ResolvedIotaDocument> {
    let resolver_builder: ResolverBuilder = ResolverBuilder::new().await?;
    let resolver: Resolver = resolver_builder.client(client).build().await?;
    resolver.resolve(did).await
}

Node.js

const {
  DID,
  Resolver,
  ResolvedDocument,
  Client,
} = require('@iota/identity-wasm/node');

async function buildAndResolve(client, did) {
  const resolver = await Resolver.builder().client(client).build();
  const resolvedDocument = await resolver.resolve(did);
  return resolvedDocument;
}

In the example above the resolver will automatically try to resolve the DID from the network specified in the did (See DID Format). If the resolver was not built with a client configured for the given network name then an error will be thrown. Note that the ResolverBuilder can configure the Resolver to use multiple networks as long as they have distinct valid names (max six characters).

Note that in the context of an identity managed by an Account the DID document can also be resolved by simply calling the resolve method on the Account directly.

Resolution in the context of Verifiable Presentations

As explained in Verifiable Presentations one resolves the DID Documents of the credential issuers and presentation holder during verification of a verifiable presentation. Resolving the necessary DID Documents is done automatically when verifying presentations via the Resolver, but there are certain advanced use cases where more control is desired. To accommodate for such situations the Resolver also comes equipped with additional stand alone methods that enable:

• resolving a presentation holder's DID Document
• resolving all DID Documents of the distinct issuers of the credentials contained in the presentation
• resolving the issuer's DID Document for a given verifiable credential

Resolving the history of a DID Document.

The fact that a DID Document can be updated implies that the state of the DID Document can change over time, or in other words the result of resolving a DID also depends on when this operation was carried out. The Resolver provides a way to view the entire history of a DID Document (up to the time when the method is called).

Rust

use identity_iota::client::Resolver;
use identity_iota::iota_core::IotaDID;
use identity_iota::client::DocumentHistory;
use identity_iota::client::Result;


async fn call_resolve_history(did: IotaDID) -> Result<DocumentHistory> {
    let resolver: Resolver = Resolver::new().await?;
    resolver.resolve_history(did).await?
}

Node.js

const { DID, Resolver, DocumentHistory } = require('@iota/identity-wasm/node');

async function callResolveHistory(did) {
  const resolver = new Resolver();
  const documentHistory = await resolver.resolveHistory(did);
  return documentHistory;
}

Complete examples

This section shows complete examples from the Iota Identity Framework code base. The first example creates a DID Document, publishes it to the Tangle and then resolves it.

Rust

v0.6/examples/low-level-api/resolve_did.rs

loading...

See full example on GitHub

Node.js

v0.6/bindings/wasm/examples/src/resolve_did.js

loading...

See full example on GitHub

This second example demonstrates creating, publishing changes and then resolving the history of a DID Document.

Rust

v0.6/examples/low-level-api/resolve_history.rs

loading...

See full example on GitHub

Node.js

v0.6/bindings/wasm/examples/src/resolve_history.js

loading...

See full example on GitHub

Note that this example used the Client to resolve the history of the DID Document, but one could also use the Resolver for this task.