# did-resolver

> Resolve DID documents

Latest version **6.0.0** (published 2026-09-21) · Apache-2.0 license · 0 weekly downloads

## Install

```sh
npm install did-resolver
pnpm add did-resolver
yarn add did-resolver
bun add did-resolver
```

## Health

**Score 75/100 (B)** — status: active.

Positive: has types; esm support; no vulnerabilities; has provenance; recently updated; high maintenance score; high quality score.

Warnings: low downloads.

## Facts

| | |
|---|---|
| Version | 6.0.0 |
| Published | 2026-09-21 |
| First published | 2018-02-20 |
| Weekly downloads | 0 |
| License | Apache-2.0 |
| TypeScript types | bundled |
| Module format | ESM + CommonJS |
| Dependencies | 0 |
| Unpacked size | 72.8 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Provenance | attested (GitHub Actions) |
| GitHub stars | 231 |
| Author | Pelle Braendgaard |
| Maintainers | simonas-notcat, mirceanis, uport-automation-bot, pelleb, mike.xu |

## Links

- npm: https://www.npmjs.com/package/did-resolver
- Repository: https://github.com/decentralized-identity/did-resolver
- npm.io page: https://npm.io/package/did-resolver

## Recent versions

- 6.0.0 (latest) — 2026-09-21
- 5.0.0-feat-publishing-maintenance.1 (preview) — 2026-05-04
- 0.0.7-alpha.0 (alpha) — 2019-06-12
- 5.0.1 — 2026-05-04
- 5.0.0 — 2026-05-04
- 4.1.0 — 2023-03-08
- 4.0.1 — 2022-10-17
- 4.0.0 — 2022-08-02
- 3.2.2 — 2022-06-05
- 3.2.1 — 2022-06-05
- 3.2.0 — 2022-03-29
- 3.1.5 — 2021-12-09
- 3.1.4 — 2021-12-04
- 3.1.3 — 2021-10-26
- 3.1.2 — 2021-09-29
- … 26 more at https://npm.io/package/did-resolver/versions

## README

[![npm](https://img.shields.io/npm/dt/did-resolver.svg)](https://www.npmjs.com/package/did-resolver)
[![npm](https://img.shields.io/npm/v/did-resolver.svg)](https://www.npmjs.com/package/did-resolver)
[![codecov](https://codecov.io/gh/decentralized-identity/did-resolver/branch/master/graph/badge.svg)](https://codecov.io/gh/decentralized-identity/did-resolver)

# Typescript DID Resolver

This library is intended as a simple common interface for javascript applications to resolve DID documents from
Decentralized Identifiers (DIDs).

This is intended to support the proposed [Decentralized Identifiers](https://w3c.github.io/did-core/#identifier) spec
from the [W3C Credentials Community Group](https://w3c-ccg.github.io).

The library does not implement any specific DID method, but allows DID method implementors to release npm packages that
applications can add.

## DID verification relationships

The `VerificationRelationship` runtime constants represent the verification relationships defined by DID Core:

```ts
import { VerificationRelationship, type DIDDocument } from 'did-resolver'

const document: DIDDocument = {
  id: 'did:example:123',
  [VerificationRelationship.Authentication]: ['did:example:123#key-1'],
}
```

The corresponding `VerificationRelationship` type also accepts the underlying string literals. The existing
`KeyCapabilitySection` type remains available as a backwards-compatible alias.

## Configure `Resolver` object

You are now required to preconfigure a resolver during instantiation. The `Resolver` constructor expects a registry of
methods mapped to a resolver function. For example:

```js
{
  ethr: resolve,
  web: resolve
}
```

Each method resolver should expose a function called `getResolver` which will return an object containing one of these
key/value pairs. Then you can flatten them into one object to pass into the `Resolver` constructor.

```js
import { Resolver } from 'did-resolver'
import ethr from 'ethr-did-resolver'
import web from 'web-did-resolver'
import sov from 'sov-did-resolver'

//returns an object of { methodName: resolveFunction}
ethrResolver = ethr.getResolver()
webResolver = web.getResolver()

//If you are using multiple methods you need to flatten them into one object
const resolver = new Resolver({
  ...ethrResolver,
  ...webResolver,
})

//If you are using one method you can simply pass the result of getResolver( into the constructor
const resolver = new Resolver(ethrResolver)
```

### Using legacy DID Method resolvers

DID Method resolvers created before version `3.0.0` of this library can be used as legacy resolvers.

```js
import { Resolver } from 'did-resolver'
import web from 'web-did-resolver'
import sov from 'sov-did-resolver'

//returns an object of { methodName: resolveFunction}
webResolver = web.getResolver()
sovResolver = sov.getResolver()

//If you are using multiple methods you need to flatten them into one object
const resolver = new Resolver({}, {
  legacyResolvers: {
    ...webResolver,
    ...sovResolver,
  }
})

//If you are using one method you can simply pass the result of getResolver( into the constructor
const resolver = new Resolver(ethrResolver)
```

## Resolving a DID document

The resolver presents a simple `resolve()` function that returns a ES6 Promise returning the DID document.

```js
resolver.resolve('did:ethr:0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74/some/path#fragment=123').then(doc => console.log)

// You can also use ES7 async/await syntax
const doc = await resolver.resolve('did:ethr:0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74/some/path#fragment=123')
```

## Caching

Resolving DID Documents can be expensive. It is in most cases best to cache DID documents. Caching is controlled via the `cache` option, which accepts a boolean value or a custom `DIDCache` function.

### Built-in caching

The built-in cache uses a `Map` and does not have an automatic TTL, so entries don't expire. This is fine in most web, mobile and serverless contexts. If you run a long-running process, consider using a custom cache with expiration.

Enable the built-in cache by passing `cache: true` to the constructor:

```js
const resolver = new Resolver({
  ethr,
  web
}, {
  cache: true
})
```

### Disabling cache

To disable caching entirely, pass `cache: false`:

```js
const resolver = new Resolver({
  ethr,
  web
}, {
  cache: false
})
```

### Per-call cache control

You can override the global cache setting on a per-call basis using the `cache` option in `DIDResolutionOptions`:

```js
// Global cache enabled, but disable for this specific resolution
const doc = await resolver.resolve('did:ethr:0xabcd...', { cache: false })

// Global cache disabled, but enable for this specific resolution
const doc = await resolver.resolve('did:ethr:0xabcd...', { cache: true })
```

### Custom cache implementation

For advanced use cases, implement a custom `DIDCache` function. It receives the parsed DID, a resolve function, and optional resolution options:

```js
const customCache: DIDCache = async (parsed, resolve, options) => {
  // Respect per-call cache control
  if (options?.cache === false) return await resolve()
  
  const cached = cache.get(parsed.didUrl)
  if (cached !== undefined) return cached
  
  const doc = await resolve()
  cache.set(parsed.didUrl, doc, 60000) // 60s TTL
  return doc
}

const resolver = new Resolver({
  ethr,
  web
}, {
  cache: customCache
})
```

## Implementing a DID method

Each DID method will have its own methods for looking up an identifier on its respective blockchain or other
decentralized storage mechanism.

To avoid misconfiguration, method implementers should export a `getResolver()` function which returns an object mapping
the method name to a `resolve(did: string, parsed: ParsedDID, didResolver: DIDResolver, options: DIDResolutionOptions)`
function. e.g. `{ ethr: resolve }`.

The resolve function should accept a did string, and an object of
type [ParsedDID](https://github.com/decentralized-identity/did-resolver/blob/master/src/resolver.ts#L112)

```js
export function getResolver() {
  async function resolve(
    did: string,
    parsed: ParsedDID,
    didResolver: Resolver,
    options: DIDResolutionOptions
  ): Promise<DIDDocument> {
    console.log(parsed)
    // {method: 'mymethod', id: 'abcdefg', did: 'did:mymethod:abcdefg/some/path#fragment=123', path: '/some/path', fragment: 'fragment=123'}
    const didDoc = ...// lookup doc
    // If you need to lookup another did as part of resolving this did document, the primary DIDResolver object is passed in as well
    const parentDID = await didResolver.resolve(...)
    // Return the DIDResolutionResult object
    return {
      didResolutionMetadata: { contentType: 'application/did+ld+json' },
      didDocument: didDoc
      didDocumentMetadata: { ... }
    }
  }

  return { myMethod: resolve }
}
```

The MyMethod `getResolver()` result could then be passed into the DIDResolver constructor. Note that it should be
flattened if used with other methods as well.

```js
import { DIDResolver } from 'did-resolver'
import MyMethod from 'mymethod-did-resolver'

const myResolver = MyMethod.getResolver()
const resolver = new DIDResolver(myResolver)
```

### Per-Method Parsing

If your method has special syntax constraints beyond the base DID Core v1.0 spec, you can attach a method-specific parser to your resolver. This allows stricter syntax validation without duplicate parsing work.

**Architecture:** Method-specific parsers receive a DID Core v1.0 compliant `ParsedDID` result from the global parser and only check method-specific syntax constraints. This ensures all DIDs pass DID Core v1.0 parsing first, then method-specific syntax rules. The parser is part of the resolver enhancement — both are exported together from `getResolver()`.

```js
export function getResolver() {
  async function resolve(
    did: string,
    parsed: ParsedDID,
    didResolver: Resolver,
    options: DIDResolutionOptions
  ): Promise<DIDDocument> {
    console.log(parsed)
    // {method: 'mymethod', id: 'abcdefg', did: 'did:mymethod:abcdefg/some/path#fragment=123', path: '/some/path', fragment: 'fragment=123'}
    
    const didDoc = ... // lookup doc
    // If you need to lookup another did as part of resolving this did document, the primary DIDResolver object is passed in as well
    const parentDID = await didResolver.resolve(...)
    
    // Return the DIDResolutionResult object
    return {
      didResolutionMetadata: { contentType: 'application/did+ld+json' },
      didDocument: didDoc,
      didDocumentMetadata: { ... }
    }
  }

  function parser(parsed: ParsedDID): ParsedDID | null {
    // Receive DID Core v1.0 compliant ParsedDID from global parser
    // Only add method-specific syntax constraints
    
    // Example: enforce minimum id length for this method
    if (parsed.id.length < 5) {
      return null  // Reject with invalidDid error
    }
    
    // Can refine/enrich the parsed result if needed
    return {
      ...parsed,
      methodSpecificField: 'value'
    }
  }

  // Attach parser to resolver — this is required for the parser to be used
  resolve.parser = parser

  return { myMethod: resolve }
}
```

Consumers register the resolver normally — the parser is part of it:

```js
import { Resolver } from 'did-resolver'
import MyMethod from 'mymethod-did-resolver'

// For a single method
const resolver = new Resolver(MyMethod.getResolver())

// For multiple methods, flatten them together
import OtherMethod from 'other-did-resolver'
const resolver = new Resolver({
  ...MyMethod.getResolver(),
  ...OtherMethod.getResolver(),
})
```

**Benefits:**

- Method libraries control their own parse→resolve pipeline as a cohesive unit
- Parser is discovered automatically via the resolver's `.parser` property
- No duplicate parsing work
- All DIDs guaranteed to pass DID Core v1.0 parsing first
- Method parsers only implement method-specific syntax constraints
- Parsers can refine/enrich the parsed result if needed
- If parser returns `null`, resolution fails with `invalidDid` error

---
_Source: https://npm.io/package/did-resolver · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._