Skip to content
DID.is Docs

Introduction

DID.is resolves decentralized identifiers (DIDs) and reports the evidence behind each result. Instead of a trust score, every result lists what was checked, what that check proves and what it does not prove.

You can use it in two ways:

  • Web app at did.is: paste an identifier, a credential or an agent URL and read the result.
  • Public API at https://did.is/api: anonymous, free and rate-limited, with SDKs for TypeScript and Python.

In plain words

Section titled “In plain words”

A DID is like a digital business card that its owner publishes and controls. DID.is reads the card and writes down what was checked: whether it is intact, whether its keys are usable, whether the owner’s website links back to it and whether its history can be proven. It does not tell you to trust the card; it shows where the evidence stops. See Use cases for six everyday examples.

What DID.is does

Section titled “What DID.is does”
Task Web app API
Resolve a DID and explain the result did.is GET /v1/resolve/{did}
Check a did:web setup (did.json location, TLS, id, keys) did.is/tools/did-web GET /v1/resolve/{did}
Standard W3C DID Resolution output — GET /1.0/identifiers/{did}
Watch a resolution step by step Result page, telemetry level GET /v1/stream/{did}
Verify a verifiable credential did.is/verify POST /v1/credentials/verify
Evaluate a policy did.is/policies POST /v1/policies/evaluate
Inspect an MCP server or A2A agent card did.is/agents, or did.is/tools/mcp-check with a README badge /v1/mcp/inspect, /v1/a2a/inspect
Verify a delegation chain for an agent did.is/agents /v1/agents/verify-delegation
Find identifiers that opted in to be listed did.is/discover GET /v1/directory

Supported DID methods: did:key, did:jwk, did:web and did:webvh (1.0). Other methods return 501 METHOD_NOT_SUPPORTED.

What a result tells you

Section titled “What a result tells you”

Each resolution returns a verdict (one headline plus short statements) and seven evidence dimensions: document integrity, key material, update authority, origin binding, transport security, verifiable history and real-world identity. Each dimension has a state such as ESTABLISHED or NOT_ESTABLISHED and states in plain words what it proves and what it does not. See Core concepts.

What DID.is does not claim

Section titled “What DID.is does not claim”
  • It does not verify legal identity. The organization dimension is always NOT_ESTABLISHED. A DID that resolves correctly says nothing about who runs it.
  • It does not score. There is no aggregate number. Policies are explicit rules you write; a rule that cannot be evaluated is INDETERMINATE, never PASS.
  • Observations are not history proofs. For did:web, DID.is records what it saw. Only did:webvh carries a signed, hash-chained history.
  • A valid credential signature does not make the issuer authoritative for the claims in it.
  • An agent’s self-description is self-reported. MCP server info and A2A cards are inspected and fingerprinted, not certified.

Public and private use

Section titled “Public and private use”

Public API requests may appear in an identifier’s public observation history. If you resolve identifiers that must not be disclosed, use a project in the console, which adds private resolution, API keys, monitoring and signed webhooks.

Next steps

Section titled “Next steps”