IETF draft 'ID MANDAT' gives a company's agents a machine-readable mandate

IETF draft ‘ID MANDAT’ gives a company’s agents a machine-readable mandate

by

A signed request proves an agent holds a key. It does not prove which company stands behind the agent, or what the agent was told it may do. On 16 October 2026, Manja König published an Internet-Draft that tries to close that gap with a small JSON file on the company’s own domain, a DNS proof record, and a registry answer that reports how far it has checked.

What happened

The document, draft-koenig-idmandat-credential-00, is an individual Internet-Draft — not a working-group product, and not endorsed by the IETF. It has informational intended status, expires on 19 April 2027, and describes a deployed beta (version 0.3) with a reference lookup service at idmandat.com. The draft is explicit that its job is complementary to work such as Web Bot Auth: that work lets a recipient verify that a request was signed by the holder of a key and, via the Signature-Agent header field, where the key can be found — but it “explicitly does not say who operates the agent or what it is authorised to do.”

The proposed structure has three parts:

  • A credential file at /.well-known/idmandat.json on the company’s own domain, served as application/json over HTTPS. Its domain member MUST equal the host it was fetched from. organization carries at least the legal name and ISO 3166-1 country, and may carry legal form, address, commercial-register entry, VAT ID and an imprint URL.
  • Per-agent entries with id, name, role, an isHuman flag that MUST be false, optional endpoint and protocol hints (a2a, mcp), an optional human contact, and an optional signatureAgent reference — one HTTPS URL, or up to three, naming the key directory used in the Signature-Agent header.
  • A mandate object with may and mayNot arrays of capability names. The draft recommends a shared vocabulary — answer_product_questions, explain_prices, reserve_appointment, create_quote, take_order, conclude_contract, trigger_payment, share_personal_data, give_legal_advice, give_medical_advice — and says a mandate SHOULD state what the agent may not do as well as what it may. An optional bindingOnlyAfter field records when an action becomes binding, for example “confirmation by a human”.

Domain binding comes from DNS. The company publishes a TXT record at _idmandat.<domain> containing v=idmandat1; file=/.well-known/idmandat.json. The registry only reports an entry at the registered level when the domain in the file, the DNS record and the fetched file agree. Above that sits verified: name and address match the domain’s imprint, and the commercial-register entry (or a valid VAT ID) exists and matches. Below it sits listed_unverified, where the company listed itself and nothing was checked.

Answers are signed and short-lived. The reference registry answers GET requests at https://idmandat.com/api/v1/verify, by domain or by key directory, in a read-only interface that needs no account. Answers are signed with Ed25519, carry key_id, issued_at and expires_at (valid for 15 minutes), and must be checked against published keys. An answer with signed: false “MUST NOT be treated as evidence.” Revoked, suspended and expired entries are reported explicitly, and a recipient must not rely on earlier answers for them.

At the time of writing, a live query to the reference registry returned a signed answer for an unregistered domain with "level": "none", "version": "0.3.0-beta", a 15-minute validity window, and the notice that ID MANDAT confirms identity and authority — not creditworthiness, trustworthiness or quality.

Why it matters for KYA

This is the principal question, written into a file format. Most agent-identity plumbing answers “is this the agent it claims to be?” ID MANDAT answers “which legal entity declared this agent, and what did it authorise?” — with a machine-readable mayNot list, which is the part most delegation systems leave implicit.

Three design choices are worth studying:

  • The company owns the credential; the registry only reports on it. The file stays readable without any registry, and the registry’s role is to confirm the domain link and, optionally, the register entry. That avoids making a single vendor the root of agent identity.
  • Verification levels are named honestly. “Listed”, “registered” and “verified” are distinct, “no entry” MUST NOT be read as a sign of wrongdoing, and the answer states that agent details are “declarations of the operator and not checked by the registry.” That is the opposite of the binary “trusted / untrusted” badge that agent marketplaces tend to invent.
  • It stops where its evidence stops. The security considerations say the registry does not confirm that the agent exists, that a power of attorney was granted, or that the agent respects its mayNot list. It explicitly does not define authorisation of a single transaction (amount, purpose, time window) or delegation between agents. Those, the draft says, belong to other layers.

That last point is the honest limit: a declared mandate is policy, not enforcement. A counterparty still has to enforce its own limits, and a mayNot entry is only as good as the operator’s willingness to be held to it. The draft’s signatureAgent link is likewise only a declaration — the registry does not fetch the key directory or verify control of it, and recipients are told to treat declared_only as weak and ambiguous as no result.

For practitioners, the useful takeaway is less “implement this draft” than “this is the shape of the answer you will be asked for”: a domain-anchored, signed statement of principal, agent and scope, with revocation and an explicit check level. Any agent-onboarding questionnaire can be scored against it today.

Sources

  • IETF Datatracker, draft-koenig-idmandat-credential-00, “A Machine-Readable Credential for the Agents of a Company (ID MANDAT)”, Manja König, 16 October 2026 — datatracker.ietf.org.
  • Reference registry and lookup interface described by the draft — idmandat.com (live query: /api/v1/verify?domain=example.com, 17 October 2026).
  • IETF, RFC 8615, “Well-Known Uniform Resource Identifiers (URIs)” — the registry the draft asks to extend — rfc-editor.org.
  • IETF, RFC 8032, “Edwards-Curve Digital Signature Algorithm (EdDSA)” — the signature scheme used for registry answers — rfc-editor.org.

Note: status, scope and limitations are as stated in the draft itself. It is an individual submission with no IETF standing; the beta deployment and registry behaviour were checked directly on 17 October 2026.

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.