A Machine-Readable Credential for the Agents of a Company (ID MANDAT)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [WEBBOTAUTH], 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 (Section 2);¶
• a DNS TXT record that ties the file to the domain (Section 3);¶
• the lookup answer of a registry that checks both, including the possibility of revoking an entry (Section 5).¶

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

2. The Credential File

A company that wants to declare its agents publishes a JSON document [RFC8259] 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 [WEBBOTAUTH]). A recipient can use it to find the company from the key (Section 5).¶

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.¶

{
  "idmandat": "0.1",
  "domain": "example.com",
  "organization": {
    "name": "Example GmbH",
    "country": "DE",
    "vatId": "DE123456789",
    "imprint": "https://example.com/impressum"
  },
  "agents": [
    {
      "id": "captain",
      "name": "Captain",
      "role": "Appointments and product questions",
      "isHuman": false,
      "protocols": ["a2a", "mcp"],
      "mandate": {
        "may": ["answer_product_questions", "reserve_appointment"],
        "mayNot": ["conclude_contract", "trigger_payment"],
        "bindingOnlyAfter": "confirmation by a human"
      },
      "signatureAgent": "https://bot.example.com"
    }
  ],
  "verification": {
    "registry": "https://idmandat.com",
    "dns": "_idmandat.example.com"
  },
  "updated": "2026-10-16"
}

3. 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.¶

4. 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.¶

5. 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.¶

6. 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 (Section 5.2) 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 [WEBBOTAUTH]) 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.¶

7. 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.¶

8. IANA Considerations

Acknowledgments

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

Author's Address