ID MANDAT

Osnabrück DE kontakt@idmandat.com https://idmandat.com

AI agents identity mandate well-known URI Automated software agents increasingly act for companies: they ask for quotes, book appointments and place orders. A recipient can verify, for example with Web Bot Auth, that a request was signed by the holder of a key. That does not tell the recipient which company stands behind the agent or what the agent is allowed to do on its behalf. This document describes a small credential file that a company publishes on its own domain under /.well-known/idmandat.json, a DNS TXT record that links the file to the domain, and the answer format of a public registry that checks both and reports the result in a digitally signed response. The credential states, by declaration of the company, which agents act for it and what each agent may and may not do. It does not make claims about creditworthiness, trustworthiness or quality.

Introduction A website visitor can look at an imprint and judge whether a company looks serious. An automated agent cannot. Work on authenticating automated traffic, such as , lets a recipient check that a request was signed by the holder of a key and, through the Signature-Agent header field, where that key can be found. That work explicitly does not say who operates the agent or what it is authorised to do. This document specifies a complementary, voluntary and declarative layer:

• a credential file under the company's own domain, naming the company, its agents, and for each agent what it may and may not do ();
• a DNS TXT record that ties the file to the domain ();
• the lookup answer of a registry that checks both, including the possibility of revoking an entry ().

The credential belongs to the company, not to the registry. It stays valid and readable without any registry.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Status of this Document This is an individual submission describing a deployed beta (version 0.3). It is not the product of an IETF working group. The lookup interface described in is operated at https://idmandat.com and is described here so that others can implement clients and compatible registries.

The Credential File A company that wants to declare its agents publishes a JSON document at: https://example.com/.well-known/idmandat.json The document is served with media type application/json over HTTPS. Its top-level members are:

idmandat

Version of this specification, as a string (for example "0.1").

domain

The domain that publishes the file. It MUST equal the host from which the file was fetched.

organization

An object with at least "name" (the legal name of the company as in its imprint or commercial register) and "country" (ISO 3166-1 alpha-2). It MAY contain "legalForm", "address", "industry", "register" (court and number), "vatId" and "imprint" (a URL).

agents

An array of agent objects (see below).

verification

An object naming the registry and the DNS name of the proof record.

updated

Date of the last change, as an ISO 8601 date.

Each agent object has the following members:

id, name, role

Identifier, display name and short description of the task of the agent.

isHuman

MUST be false. An agent declared under this document does not present itself as a human being.

endpoint, protocols

OPTIONAL. Where the agent can be reached and which protocols it speaks (for example "a2a", "mcp").

mandate

An object with "may" and "mayNot", arrays of capability names, and OPTIONAL "bindingOnlyAfter", a short text saying from when an action becomes binding (for example after confirmation by a human). A mandate SHOULD state what the agent may not do as well as what it may do.

humanContact

OPTIONAL. Where a human can be reached.

signatureAgent

OPTIONAL. One https URL, or an array of at most three, naming the key directory with which the agent signs its requests (the value that appears in the Signature-Agent header field of ). A recipient can use it to find the company from the key ().

For "may" and "mayNot" the following capability names are RECOMMENDED so that different implementations read them the same way: answer_product_questions, answer_service_questions, explain_prices, check_availability, prepare_appointment, reserve_appointment, book_appointment, create_quote, take_order, qualify_lead, forward_request, conclude_contract, trigger_payment, share_personal_data, give_legal_advice, give_medical_advice. Other names are allowed. The following is a non-normative example.

The DNS Proof Record The file alone shows only that whoever controls the web server published it. To tie it to the domain holder as well, the company publishes a TXT record at the name "_idmandat" below the domain: _idmandat.example.com. IN TXT "v=idmandat1; file=/.well-known/idmandat.json" A checker accepts an entry at the level "registered" only if the domain in the file, the DNS record and the fetched file agree.

Check Levels A registry reports how far it has checked an entry. The levels used by the registry described here are:

listed_unverified

The company listed itself; nothing was checked.

registered

File and DNS proof record agree with the domain.

verified

In addition, name and address match the imprint of the domain, and the commercial register entry (or, for companies without one, a valid VAT identification number) exists and matches. Checks are repeated regularly.

Where no level applies the answer says so explicitly. The text "no entry" MUST NOT be read as a sign of wrongdoing.

Registry Lookup and Signed Answers A registry offers a read-only HTTP interface that needs no account. The reference registry answers GET requests on https://idmandat.com/api/v1/verify with a JSON object. A query names either a domain ("domain", optionally with an agent name) or a key directory ("signature_agent", the address from the Signature-Agent header field or the whole header value). An answer for an entry contains at least: "domain", "registered", "level", and, where applicable, "organization", "agents" (with "may" and "mayNot"), and "mandate_source" with the value "declared_by_operator". The answer states that the agent details are declarations of the operator and not checked by the registry.

Entry States An entry that is no longer valid is reported explicitly: "registered" is false, "level" is "none", "entry_state" is one of "revoked", "suspended" or "expired", "state_since" gives the date, and for a revocation "revoked" is true. A recipient MUST NOT rely on earlier answers for such an entry.

Lookup by Key Directory For a query by "signature_agent" the registry normalises the address (https only, lower-case host, default port removed, trailing slash removed, query kept; a well-known key directory path is shortened to the origin) and compares it with the declarations in the entries. The "resolution" is one of: none (no entry declares it), ambiguous (more than one entry declares it; the answer lists them and MUST NOT name one as responsible), or a match. A match carries "key_directory_link", with the value "same_domain" if the directory is on the same registrable domain as the entry (a hint) or "declared_only" (the company merely declares it). The registry does not fetch the key directory and does not verify that the company controls it. The link rests on the declaration of the company.

Digital Signature Answers are signed with Ed25519 . The answer carries "signed" (true or false), "key_id", "issued_at" and "expires_at" (valid for 15 minutes) and a "signature" object with "alg" and "value". The signed bytes are the UTF-8 encoding of the answer without the "signature" member, with all object members sorted recursively by key, written compactly (no insignificant white space), without escaping non-ASCII characters or the solidus. The value is base64url without padding. Public keys are published at https://idmandat.com/api/v1/keys. An answer with "signed" false MUST NOT be treated as evidence.

Security Considerations The statements about agents and their permissions come from the company itself. The registry confirms identity of the company and that the declaration is published on its domain. It does not confirm that the agent exists, that a power of attorney was actually granted, or that the agent respects its "mayNot" list. A recipient decides what to do with the answer and MUST enforce its own limits. The link between a key directory and a company () is a declaration. A company may declare a key directory it does not control. Recipients SHOULD treat "declared_only" as weak and "ambiguous" as no result. Answers are valid for a short time and are signed so that they can be cached and replayed only within that time. A client MUST check "expires_at", the domain in the answer and the signature against the published keys, and SHOULD pin the "alg". A valid signature on a request (for example as in ) shows that the request came from the key holder. It is not evidence of an entry in a registry, and the absence of an entry is not evidence against the agent. This document does not define authorisation of single transactions (amount, purpose, time window) or delegation between agents. Those belong to other layers.

Privacy Considerations The credential is public by design and SHOULD contain business contact points rather than personal data. The reference registry stores no record of which domains were queried, no addresses of clients and no persons. It keeps only a count of queries per day. Other registries SHOULD be equally restrictive.

IANA Considerations

Well-Known URI This document requests registration of the following in the "Well-Known URIs" registry :

URI suffix:

idmandat.json

Change controller:

ID MANDAT, kontakt@idmandat.com

Specification document(s):

This document

Status:

provisional

Underscored DNS Node Name This document requests registration of the following in the "Underscored and Globally Scoped DNS Node Names" registry :

RR Type:

TXT

_NODE NAME:

_idmandat

Reference:

This document

References Normative References Informative References IETF Web Bot Auth Working Group

Acknowledgments The author thanks the people who commented on the early versions of the format.