did:web - a cryptographic identity document that agents can verify
Tests for a W3C did:web identity document at /.well-known/did.json verifying ownership of your domain.
What this signal tests
We check for /.well-known/did.json - a Decentralized Identifier document using the W3C did:web method. The document declares an `id` matching `did:web:{your-host}`, plus one or more `verificationMethod` entries containing public keys. It is a cryptographically anchored way for an agent or another website to confirm "yes, this domain really did sign that message."
Why it matters for your visibility in AI
did:web is forward-looking infrastructure for agent-to-agent commerce. When one agent transacts with another, both sides eventually need a way to prove who they are - not just "the domain in the URL bar looks right" but "the response was cryptographically signed by the keypair this domain has published." did:web is the simplest of the W3C DID methods because it uses the existing DNS and HTTPS trust chain rather than requiring a blockchain. Adoption is still small - DIDs are mostly used today in verifiable-credentials pilots, supply-chain provenance, and a few agent-network experiments. But as agent-to-agent payments and contracts move from prototype to production over the next few years, sites with a published did:web will be ready and sites without one will scramble. The consequence today is minimal; the consequence in 2027 could be meaningful. Publishing one is a small, one-time investment that future-proofs your domain's identity layer.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| Valid DID document. |
How we test it
We send GET /.well-known/did.json and check several things. The response must be 200 with valid JSON. The `id` field must exactly equal `did:web:{your-hostname}` (with hostname URL-encoded per the spec). At least one entry in `verificationMethod` must be present and contain a `publicKeyJwk` or `publicKeyMultibase` field. We also check the `@context` includes the DID core context. Content type should be application/did+json or application/json.
Show technical detection method
GET /.well-known/did.json; valid JSON with id matching did:web:{host} and verificationMethod.
If your site fails: how to fix it
- Generate a keypair (Ed25519 or secp256k1 are common choices) using a DID-aware tool such as Spruce DIDKit, the DIF universal-resolver, or veramo.
- Construct the DID document with `id` set to `did:web:{your-hostname}` and the public key serialised under `verificationMethod`.
- Store the private key in your secrets manager - losing it means losing the ability to sign as your did:web identity.
- Publish the document at /.well-known/did.json with Content-Type: application/did+json and a 2xx status, served over HTTPS with a valid certificate.
- Read the did:web specification at https://w3c-ccg.github.io/did-method-web/ before implementing - this is best handled by a developer comfortable with cryptographic key management.
Quick facts
| Maturity | EMERGING |
|---|---|
| Weight | low |
| Category | Emerging Standards |
Primary sources
Related signals
Frequently asked questions
Is did:web a real standard?
DIDs are a full W3C Recommendation. The did:web method is one of several method specifications under W3C Credentials Community Group work. It is mature enough for production but adoption is concentrated in verifiable-credentials and supply-chain pilots, not yet mainstream web.
Which AI systems use did:web today?
Very few in the consumer assistant space. Adoption is mostly in agent-to-agent commerce experiments, decentralised identity wallets, and EU-backed digital-identity pilots. This is forward-looking infrastructure, not present-day necessity.
What's the risk of publishing a key?
The public key is meant to be public - that is the whole point. The risk is losing the corresponding private key, which would force you to rotate the DID document. Treat the private key like a TLS certificate's private key: HSM or secrets manager.
Will fixing this still matter in two years?
Plausibly yes, especially if agent-to-agent payments take off. The cost of publishing a did:web is small and one-time, so the asymmetry favours doing it. But if you have to prioritise, MCP and llms.txt deliver more value today.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.