Network Working Group M. König Internet-Draft ID MANDAT Intended status: Informational 16 October 2026 Expires: 19 April 2027 A Machine-Readable Credential for the Agents of a Company (ID MANDAT) draft-koenig-idmandat-credential-00 Abstract 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. 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. König Expires 19 April 2027 [Page 1] Internet-Draft ID MANDAT Credential October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Status of this Document . . . . . . . . . . . . . . . . . 3 2. The Credential File . . . . . . . . . . . . . . . . . . . . . 3 3. The DNS Proof Record . . . . . . . . . . . . . . . . . . . . 5 4. Check Levels . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Registry Lookup and Signed Answers . . . . . . . . . . . . . 6 5.1. Entry States . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Lookup by Key Directory . . . . . . . . . . . . . . . . . 6 5.3. Digital Signature . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 8 8.2. Underscored DNS Node Name . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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); König Expires 19 April 2027 [Page 2] Internet-Draft ID MANDAT Credential October 2026 * 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. 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 Section 5 is operated at https://idmandat.com and is described here so that others can implement clients and compatible registries. 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). König Expires 19 April 2027 [Page 3] Internet-Draft ID MANDAT Credential October 2026 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. König Expires 19 April 2027 [Page 4] Internet-Draft ID MANDAT Credential October 2026 { "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. König Expires 19 April 2027 [Page 5] Internet-Draft ID MANDAT Credential October 2026 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. 5.1. 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. 5.2. 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). König Expires 19 April 2027 [Page 6] Internet-Draft ID MANDAT Credential October 2026 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. 5.3. Digital Signature Answers are signed with Ed25519 [RFC8032]. 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. 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. König Expires 19 April 2027 [Page 7] Internet-Draft ID MANDAT Credential October 2026 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 8.1. Well-Known URI This document requests registration of the following in the "Well- Known URIs" registry [RFC8615]: URI suffix: idmandat.json Change controller: ID MANDAT, kontakt@idmandat.com Specification document(s): This document Status: provisional 8.2. Underscored DNS Node Name This document requests registration of the following in the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]: RR Type: TXT _NODE NAME: _idmandat Reference: This document 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . König Expires 19 April 2027 [Page 8] Internet-Draft ID MANDAT Credential October 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, March 2019, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019, . 9.2. Informative References [WEBBOTAUTH] IETF Web Bot Auth Working Group, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-ietf-webbotauth-httpsig-protocol-00, September 2026, . Acknowledgments The author thanks the people who commented on the early versions of the format. Author's Address Manja König ID MANDAT Osnabrück Germany Email: kontakt@idmandat.com URI: https://idmandat.com König Expires 19 April 2027 [Page 9]