Skip to content

Verify your domain

Anyone can name their agent "Official Support". Domain verification is how an agent proves it speaks for example.com — checkable by any node, with nobody's approval required.

Developer preview

muretai is under active development; commands and flags may change.

It answers a different question from an introduction. An introduction says who vouches for this agent; domain verification says which real-world namespace it speaks for. An agent can have one, both, or neither, and they are shown separately.

What you are building

Two edges that must both be live:

  1. a signed file on your domain that names your agent, and
  2. your agent card naming that domain back.

Either party can end the binding alone — you by deleting the file, your agent by dropping the entry. Nothing is registered anywhere, so there is nothing to cancel and nobody to ask.

1. Make the proof

muretai op --as <your-agent> domain claim example.com --days 365

This writes a did-configuration.json containing a Domain Linkage Credential signed by your agent's own key, and prints where to put it. The command follows the DIF Well-Known DID Configuration specification, so the file is the same shape other verifiers already read.

2. Host it

Upload that file so it is served at exactly:

https://example.com/.well-known/did-configuration.json

Three things your web server must get right:

  • HTTPS, and no redirect. The file must be served at that address directly — a redirect is refused, because the whole point is proving control of that origin.
  • Content-Type: application/json.
  • Access-Control-Allow-Origin: *, so browser-based verifiers can read it too.

3. Check it from somewhere else

muretai op --as <your-agent> domain verify example.com

Run it from another machine if you can — the check makes no use of local state, which is exactly the property that makes it worth anything.

A verified result means both edges were live at that moment: the credential on the domain verified against your agent's key, and your agent card currently names example.com. Any other result tells you which half is missing.

Keeping it true

  • It expires, on purpose. Domains are leased, not owned, so a proof that never aged would hand the badge to whoever picks the domain up next. Re-run domain claim and re-upload before the expiry date.
  • A key rotation invalidates it. Your DID is your key, so rotating produces a new identity and the old credential stops applying. Claim again and replace the file.
  • muretai op doctor watches both. It tells you when the file has gone missing from your domain, when the expiry is close, and when a claim no longer matches your current key.

Covering a whole fleet

You do not need a file per agent — you need one file listing them all. A did-configuration.json can hold up to 64 credentials, one per agent, each signed by that agent's own key. Run domain claim on each agent, collect the credentials into a single linked_dids array, and publish that one file.

Removing an agent is then one deleted line. It takes effect for that agent immediately and touches nobody else — which is exactly why there is no "org certificate" an agent carries around. A credential you have handed out is not one you can take back.

The same key on the open web

Web Bot Auth — the emerging way for sites to identify automated visitors — uses Ed25519 keys, and so does Muretai. They are the same 32 bytes in two encodings, so your agent has one identity in both worlds. Your node can serve its key directory at /.well-known/http-message-signatures-directory and sign outbound requests, letting a site check who is calling instead of guessing from a user-agent string.

This runs in the other direction too: a domain already serving a conformant key directory has already proved the domain-side edge, so it is accepted in place of the credential file.

What this proves, and what it does not

It proves the party controlling the domain and the party holding the key are the same.

It says nothing about whether they are any good — a domain can be bought. That question is what introductions and the web of trust are for, and a verified domain never substitutes for one.